移动开发中的线程池 — 基础、线程池原理及工作原理

什么是线程池？

Thread Pool（线程池）——是一种架构模式，其中固定数量的线程被预先创建并重复用于执行多个任务。无需为每个操作创建新线程（这很昂贵：JVM中每个线程约1 MB的栈内存），任务被放入队列中，由池中的空闲线程执行。在移动开发中，线程池对性能至关重要——Android和iOS限制每个应用程序的线程数。

为什么线程池在移动开发中很重要

创建线程是一项昂贵的操作：栈分配、系统注册、上下文切换。在资源受限的移动设备上，不受控制地创建线程会导致Android中的OOM（OutOfMemoryError）和iOS中的节流（throttling）。Thread Pool解决了这两个问题：限制同时运行的最大线程数并重复使用已创建的线程。Google推荐使用ExecutorService而不是原始的Thread()，Apple推荐使用OperationQueue而不是Thread。

线程池在移动开发中如何工作？

线程池基于生产者-消费者（Producer-Consumer）原理工作：任务（Runnable/Callable）被放入阻塞队列（BlockingQueue）中。池中的线程在队列中等待任务并取出执行。算法：如果空闲线程少于corePoolSize，则创建新线程。如果达到corePoolSize，任务被放入队列。如果队列已满且线程少于maximumPoolSize，则创建额外线程。超过maximumPoolSize时，任务通过RejectedExecutionHandler被拒绝。

Core Pool Size 与 Maximum Pool Size

Core pool size ——即使在空闲状态下也保留在线程池中的线程数。Maximum pool size ——队列溢出时可以创建的最大线程数。它们之间的差异是临时创建并在空闲超时后结束的额外（overflow）线程。在移动设备上，建议将corePoolSize设置为等于maximumPoolSize，以避免创建线程时的峰值负载。

Work Queue 和 RejectedExecutionHandler

BlockingQueue存储等待执行的任务。最流行的实现：LinkedBlockingQueue（无界）、ArrayBlockingQueue（有界）和SynchronousQueue（无存储——任务立即传递给线程）。当队列和池溢出时，RejectedExecutionHandler被激活。标准策略：AbortPolicy（抛出RejectedExecutionException）、CallerRunsPolicy（在发送者线程中执行）、DiscardPolicy和DiscardOldestPolicy。

// 在Android中创建线程池
val threadPool = ThreadPoolExecutor(
    corePoolSize = 2,        // 最少2个线程
    maximumPoolSize = 4,     // 最多4个线程
    keepAliveTime = 30L,     // 溢出线程生命周期
    unit = TimeUnit.SECONDS,
    workQueue = LinkedBlockingQueue<Runnable>(16),
    threadFactory = Executors.defaultThreadFactory(),
    handler = ThreadPoolExecutor.CallerRunsPolicy()
)

// 提交任务
threadPool.execute {
    val result = api.fetchData()
    runOnUiThread { showData(result) }
}

// 关闭池
threadPool.shutdown()
// 等待所有任务完成
threadPool.awaitTermination(10, TimeUnit.SECONDS)

Android中的线程池：ExecutorService

Android通过java.util.concurrent提供了几种线程池实现。Executors ——一个带有现成配置的工厂：newFixedThreadPool(n)（固定池）、newCachedThreadPool()（无界，按需创建线程）、newSingleThreadExecutor()（单线程——顺序执行）。对于移动项目，建议使用newFixedThreadPool并设置合理的限制（2-4个线程），因为缓存池可能会创建过多线程。

Android中的ThreadPoolExecutor

ThreadPoolExecutor（TPE）——ExecutorService的完整实现，具有可配置的参数。在Android中，TPE用于AsyncTask、IntentService和JobIntentService内部。参数corePoolSize、maximumPoolSize、keepAliveTime、BlockingQueue和RejectedExecutionHandler允许精细调整池的行为。Android建议：corePoolSize = CPU核心数 - 1（用于IO密集型任务）或核心数（用于CPU密集型任务）。对于典型应用程序——2-4个线程。

// Executors现成配置
// 1. 固定3线程池
val fixedPool = Executors.newFixedThreadPool(3)

// 2. 缓存池（不推荐用于移动端）
val cachedPool = Executors.newCachedThreadPool()

// 3. 单线程（序列化）
val singlePool = Executors.newSingleThreadExecutor()

// 4. 调度器（周期性任务）
val scheduler = Executors.newScheduledThreadPool(2)

// 使用Callable和Future
val future: Future<String> = fixedPool.submit(Callable {
    "Result: ${api.call()}"
})
// 获取结果（阻塞线程）
val result = future.get(5, TimeUnit.SECONDS)

// 关闭池
fixedPool.shutdownNow()

CoroutineDispatcher作为线程池

Kotlin协程提供CoroutineDispatcher——类似于线程池的抽象。Dispatchers.IO使用64个线程的池（受限）。Dispatchers.Default ——等于CPU核心数的池。CoroutineDispatcher不需要手动关闭，自动管理。如需精细调整，请通过Executors.newFixedThreadPool(2).asCoroutineDispatcher()创建自己的ExecutorCoroutineDispatcher。协程不会取代线程池，而是封装它。

iOS中的线程池：OperationQueue和GCD

iOS提供了两种管理线程池的主要机制：OperationQueue（基于GCD的高级API）和GCD DispatchQueue（低级C API）。OperationQueue通过属性maxConcurrentOperationCount封装线程池。默认情况下，OperationQueue使用系统定义的最大值（取决于系统负载）。DispatchQueue.global()提供带有系统线程池的并发队列。

OperationQueue和maxConcurrentOperationCount

OperationQueue通过maxConcurrentOperationCount管理线程池。值1创建串行队列（类似于单线程池）。值大于1 ——带有指定限制的并发池。默认情况下，maxConcurrentOperationCount = NSOperationQueueDefaultMaxConcurrentOperationCount（系统最优值，通常4-8个线程）。Operation支持依赖关系、优先级和取消。每个操作在系统池中的任何空闲线程上执行。

// OperationQueue与3线程池
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 3
queue.qualityOfService = .utility

// 创建操作
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) }
}

// 依赖关系：operation2等待operation1
operation2.addDependency(operation1)

// 添加到队列
queue.addOperations([operation1, operation2], waitUntilFinished: false)

// 取消所有操作
queue.cancelAllOperations()

GCD DispatchQueue作为线程池

DispatchQueue —— Apple的线程池。并发队列（qos: .utility）使用系统线程池，针对设备的当前负载进行了优化。不同的QoS（userInteractive、userInitiated、utility、background）映射到具有不同优先级的不同池。DispatchGroup允许同步多个任务。DispatchWorkItem支持取消和qualityOfService。如需精细控制，请通过DispatchQueue(label: qos: attributes: .concurrent)创建自己的并发队列。

// GCD DispatchQueue作为线程池
let customQueue = DispatchQueue(
    label: "com.app.background",
    qos: .utility,
    attributes: .concurrent,
    autoreleaseFrequency: .workItem
)

// 向池提交任务
customQueue.async { self.processFile(file1) }
customQueue.async { self.processFile(file2) }

// DispatchGroup用于同步
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() // 两个任务均已完成
}

// 通过信号量限制并发
let semaphore = DispatchSemaphore(value: 3)
for url in urls {
    pool.async {
        semaphore.wait()
        download(url)
        semaphore.signal()
    }
}

线程池的配置参数

线程池的配置直接影响应用程序的性能。错误的参数会导致CPU利用不足（线程太少）或系统过载（线程太多）。在移动应用中，由于资源有限和能耗问题，最优值不同于服务器值。主要参数：corePoolSize、maxPoolSize、queue capacity和keepAliveTime。

计算最优池大小

IO密集型任务的公式：corePoolSize = CPU核心数 × 2（线程等待输入/输出）。CPU密集型任务：corePoolSize = CPU核心数（线程持续忙于计算）。在现代移动设备上（6-8个核心），CPU密集型任务需要6-8个线程，IO密集型任务需要12-16个线程。实际测试表明，对于典型的移动应用程序，3-4个线程是最优的——更多线程会增加能耗而不会提高性能。

Queue Capacity和溢出时的行为

任务队列（work queue）的大小决定了可以等待执行的任务数量。无界队列（无限制的LinkedBlockingQueue）在任务快速到达时可能导致OOM。有界队列（固定大小的ArrayBlockingQueue）在溢出时拒绝任务。对于移动应用程序，建议使用容量为16-32个任务的ArrayBlockingQueue。CallerRunsPolicy——移动设备的最佳RejectedExecutionHandler：它会减慢发送者（背压）而不是丢失任务。

使用线程池时的常见错误

移动应用程序开发人员在使用线程池时经常犯错误，导致崩溃、内存泄漏和不稳定的运行。最常见的：不调用ExecutorService的shutdown()，为每个操作创建新池，池过大，任务间死锁，在Android中使用CachedThreadPool。

线程池中的死锁

当池中的任务等待同一池中另一个任务的结果，但所有线程都忙于等待时，就会发生死锁。示例：任务A将任务B发送到同一池并调用future.get()——如果池已耗尽，任务A等待任务B，而任务B无法执行，因为没有空闲线程。解决方案：为不同级别的任务使用单独的池，或使用异步回调代替阻塞的.get()。

// 线程池中的死锁
val pool = Executors.newFixedThreadPool(1)

// 任务A等待任务B — 死锁！
val futureA = pool.submit {
    // 此任务永远不会执行
    val futureB = pool.submit { 42 }
    futureB.get() // 永远阻塞
}

// 修复：分离的池
val workerPool = Executors.newFixedThreadPool(2)
val callbackPool = Executors.newSingleThreadExecutor()

workerPool.submit {
    callbackPool.submit {
        // 在单独的池中执行 — 死锁不可能
    }
}

// 或使用CompletableFuture
workerPool.submit {
    CompletableFuture
        .supplyAsync { 42 }
        .thenAccept { result ->
            println(result)
        }
}

未完成的池和泄漏

在Activity中创建的ExecutorService必须在onDestroy()中结束。如果不这样做，即使在Activity销毁后，线程仍会留在内存中。解决方案：将池存储在Application范围或ViewModel中，而不是在Activity中。对于协程，使用viewModelScope或lifecycleScope。如果池是在Activity内部创建的，请务必在onDestroy()中调用pool.shutdown()。对于测试，使用es.shutdownNow()立即停止。