Thread Pool in Mobile Development — Basics, Thread Pool and How It Works

What is Thread Pool?

Thread Pool is an architectural pattern where a fixed number of threads are created in advance and reused to execute multiple tasks. Instead of creating a new thread for each operation (which is expensive: about 1 MB of stack per thread in JVM), tasks are placed in a queue and executed by available threads from the pool. In mobile development, thread pool is critical for performance — Android and iOS limit the number of threads per application.

Why Thread Pool is Important in Mobile Development

Creating a thread is an expensive operation: stack allocation, system registration, context switching. On mobile devices with limited resources, uncontrolled thread creation leads to OOM (OutOfMemoryError) on Android and throttling on iOS. Thread Pool solves both problems: it limits the maximum number of concurrently running threads and reuses already created ones. Google recommends ExecutorService over raw Thread(), Apple recommends OperationQueue over Thread.

How Does Thread Pool Work in Mobile Development?

Thread pool works on the Producer-Consumer principle: tasks (Runnable/Callable) are placed into a blocking queue (BlockingQueue). Threads from the pool wait for tasks in the queue and pick them up for execution. Algorithm: if the number of free threads is less than corePoolSize, a new thread is created. If corePoolSize is reached, the task is placed in the queue. If the queue is full and the number of threads is less than maximumPoolSize, an additional thread is created. If maximumPoolSize is exceeded, the task is rejected via RejectedExecutionHandler.

Core Pool Size vs Maximum Pool Size

Core pool size — the number of threads that are kept in the pool even when idle. Maximum pool size — the maximum number of threads that can be created when the queue overflows. The difference between them is the additional (overflow) threads that are created temporarily and terminated after the idle timeout. On mobile devices, it is recommended to set corePoolSize equal to maximumPoolSize to avoid peak loads from thread creation.

Work Queue and RejectedExecutionHandler

BlockingQueue stores tasks waiting to be executed. The most popular implementations: LinkedBlockingQueue (unbounded), ArrayBlockingQueue (bounded) and SynchronousQueue (no storage — task is passed directly to a thread). When the queue and pool are full, RejectedExecutionHandler is triggered. Standard policies: AbortPolicy (throws RejectedExecutionException), CallerRunsPolicy (executes in the caller thread), DiscardPolicy and DiscardOldestPolicy.

// Creating Thread Pool in Android
val threadPool = ThreadPoolExecutor(
    corePoolSize = 2,        // Minimum 2 threads
    maximumPoolSize = 4,     // Maximum 4 threads
    keepAliveTime = 30L,     // Overflow thread keep alive time
    unit = TimeUnit.SECONDS,
    workQueue = LinkedBlockingQueue<Runnable>(16),
    threadFactory = Executors.defaultThreadFactory(),
    handler = ThreadPoolExecutor.CallerRunsPolicy()
)

// Submitting tasks
threadPool.execute {
    val result = api.fetchData()
    runOnUiThread { showData(result) }
}

// Shutting down the pool
threadPool.shutdown()
// Waiting for all tasks to complete
threadPool.awaitTermination(10, TimeUnit.SECONDS)

Thread Pool in Android: ExecutorService

Android provides several thread pool implementations through java.util.concurrent. Executors — a factory with ready-made configurations: newFixedThreadPool(n) (fixed pool), newCachedThreadPool() (unbounded, threads created as needed), newSingleThreadExecutor() (single thread — sequential execution). For mobile projects, newFixedThreadPool with a reasonable limit (2-4 threads) is recommended, since a cached pool can create too many threads.

ThreadPoolExecutor in Android

ThreadPoolExecutor (TPE) — a full implementation of ExecutorService with configurable parameters. On Android, TPE is used inside AsyncTask, IntentService and JobIntentService. The parameters corePoolSize, maximumPoolSize, keepAliveTime, BlockingQueue and RejectedExecutionHandler allow fine-tuning the pool behavior. Recommendations for Android: corePoolSize = number of CPU cores - 1 (for IO-bound tasks) or number of cores (for CPU-bound tasks). For typical applications — 2-4 threads.

// Ready-made Executors configurations
// 1. Fixed pool of 3 threads
val fixedPool = Executors.newFixedThreadPool(3)

// 2. Cached pool (not recommended for mobile)
val cachedPool = Executors.newCachedThreadPool()

// 3. Single thread (serialization)
val singlePool = Executors.newSingleThreadExecutor()

// 4. Scheduler (periodic tasks)
val scheduler = Executors.newScheduledThreadPool(2)

// Using with Callable and Future
val future: Future<String> = fixedPool.submit(Callable {
    "Result: ${api.call()}"
})
// Getting the result (blocks the thread)
val result = future.get(5, TimeUnit.SECONDS)

// Shutting down the pool
fixedPool.shutdownNow()

CoroutineDispatcher as Thread Pool

Kotlin coroutines provide CoroutineDispatcher — an abstraction similar to thread pool. Dispatchers.IO uses a pool of 64 threads (limited). Dispatchers.Default — a pool equal to the number of CPU cores. CoroutineDispatcher does not require manual shutdown and is managed automatically. For fine-tuning, create a custom ExecutorCoroutineDispatcher via Executors.newFixedThreadPool(2).asCoroutineDispatcher(). Coroutines do not replace thread pool, but wrap it.

Thread Pool in iOS: OperationQueue and GCD

iOS provides two main mechanisms for managing thread pool: OperationQueue (high-level API built on GCD) and GCD DispatchQueue (low-level C-API). OperationQueue encapsulates a thread pool through the maxConcurrentOperationCount property. By default, OperationQueue uses a system-defined maximum (depends on system load). DispatchQueue.global() provides a concurrent queue with a system thread pool.

OperationQueue and maxConcurrentOperationCount

OperationQueue manages the thread pool through maxConcurrentOperationCount. A value of 1 creates a serial queue (analogous to a single thread pool). A value greater than 1 creates a concurrent pool with the specified limit. By default, maxConcurrentOperationCount = NSOperationQueueDefaultMaxConcurrentOperationCount (system optimum, usually 4-8 threads). Operation supports dependencies, priorities and cancellation. Each operation runs on any available thread from the system pool.

// OperationQueue with a pool of 3 threads
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 3
queue.qualityOfService = .utility

// Creating operations
let operation1 = BlockOperation {
    let data = fetchData(from: url1)
    DispatchQueue.main.async { updateUI(data) }
}

let operation2 = BlockOperation {
    let data = fetchData(from: url2)
    DispatchQueue.main.async { updateUI(data) }
}

// Dependency: operation2 waits for operation1
operation2.addDependency(operation1)

// Adding to the queue
queue.addOperations([operation1, operation2], waitUntilFinished: false)

// Canceling all operations
queue.cancelAllOperations()

GCD DispatchQueue as Thread Pool

DispatchQueue is Apple’s thread pool. A concurrent queue (qos: .utility) uses the system thread pool, optimized for the current device load. Different QoS levels (userInteractive, userInitiated, utility, background) map to different pools with different priorities. DispatchGroup allows synchronizing multiple tasks. DispatchWorkItem supports cancellation and qualityOfService. For fine-grained control, create custom concurrent queues via DispatchQueue(label: qos: attributes: .concurrent).

// GCD DispatchQueue as a thread pool
let customQueue = DispatchQueue(
    label: "com.app.background",
    qos: .utility,
    attributes: .concurrent,
    autoreleaseFrequency: .workItem
)

// Submitting tasks to the pool
customQueue.async { self.processFile(file1) }
customQueue.async { self.processFile(file2) }

// DispatchGroup for synchronization
let group = DispatchGroup()
let pool = DispatchQueue.global(qos: .utility)

pool.async(group: group) { fetchData() }
pool.async(group: group) { processImage() }

group.notify(queue: .main) {
    self.showResult() // Both tasks completed
}

// Limiting concurrency via semaphore
let semaphore = DispatchSemaphore(value: 3)
for url in urls {
    pool.async {
        semaphore.wait()
        download(url)
        semaphore.signal()
    }
}

Thread Pool Configuration Parameters

Thread pool configuration directly affects application performance. Incorrect parameters lead to CPU underutilization (too few threads) or system overload (too many). For mobile applications, optimal values differ from server-side ones due to limited resources and power consumption. The main parameters are: corePoolSize, maxPoolSize, queue capacity and keepAliveTime.

Calculating Optimal Pool Size

Formula for IO-bound tasks: corePoolSize = number of CPU cores × 2 (threads wait for I/O). For CPU-bound tasks: corePoolSize = number of CPU cores (threads are constantly busy with computations). On modern mobile devices (6-8 cores) this gives 6-8 threads for CPU-bound and 12-16 for IO-bound. Practical tests show that for a typical mobile application 3-4 threads are optimal — more threads increase power consumption without performance gains.

Queue Capacity and Overflow Behavior

The work queue size determines how many tasks can wait for execution. Unbounded queue (LinkedBlockingQueue without limit) can lead to OOM with rapid task arrival. Bounded queue (ArrayBlockingQueue with a fixed size) rejects tasks when full. For mobile applications, ArrayBlockingQueue with a capacity of 16-32 tasks is recommended. CallerRunsPolicy is the best RejectedExecutionHandler for mobile: it slows down the caller (backpressure) instead of losing the task.

Common Mistakes When Working with Thread Pool

Mobile application developers often make mistakes when using thread pool that lead to crashes, memory leaks and unstable operation. Most common: not calling shutdown() for ExecutorService, creating a new pool for each operation, too large a pool, deadlock between tasks, using CachedThreadPool on Android.

Deadlock in Thread Pool

Deadlock occurs when a task in the pool waits for the result of another task from the same pool, but all threads are busy waiting. Example: task A submits task B to the same pool and calls future.get() — if the pool is exhausted, task A waits for task B, and task B cannot execute because there are no free threads. Solution: use separate pools for different task levels or async callbacks instead of blocking .get().

// Deadlock in Thread Pool
val pool = Executors.newFixedThreadPool(1)

// Task A waits for task B — deadlock!
val futureA = pool.submit {
    // This task will never execute
    val futureB = pool.submit { 42 }
    futureB.get() // Blocks forever
}

// Fix: separate pools
val workerPool = Executors.newFixedThreadPool(2)
val callbackPool = Executors.newSingleThreadExecutor()

workerPool.submit {
    callbackPool.submit {
        // Running in a separate pool — deadlock impossible
    }
}

// Or use CompletableFuture
workerPool.submit {
    CompletableFuture
        .supplyAsync { 42 }
        .thenAccept { result ->
            println(result)
        }
}

Unterminated Pool and Leaks

An ExecutorService created in an Activity must be shut down in onDestroy(). If this is not done, threads will hang in memory even after the Activity is destroyed. Solution: keep the pool in Application scope or ViewModel, not in Activity. For coroutines, use viewModelScope or lifecycleScope. If the pool is created inside an Activity, be sure to call pool.shutdown() in onDestroy(). For testing, use es.shutdownNow() for immediate stop.