近日，某互联网团队在一次性能优化排查中遇到了一个令人费解的现象：App 原本仅有 8 个活跃线程（主线程、渲染线程、Binder 线程等），但在引入协程并同时启动 8 个异步任务后，线程总数竟在毫秒级内飙升到 16 个，瞬间翻倍。这一异常波动引发了对协程调度机制的深度追问——协程不是号称“轻量级线程”吗？为何区区 8 个异步任务能造成如此大的线程膨胀？
现场重现：8 个任务触发 8 个新线程
开发团队在日志监控中发现，当应用执行一段类似 GlobalScope.launch(Dispatchers.IO) { /* 阻塞 IO 操作 */ } 的代码时，iOS 和 Android 平台的线程数量从基线值 8 跃升至 16，且持续居高不下。进一步排查表明，这 8 个“异步任务”其实是 8 个独立的协程，每个都使用 Dispatchers.IO 调度器，并在内部调用了阻塞式库（如老式网络请求或文件 I/O）。正是这一组合，触发了线程池的“野蛮生长”。
深度解剖：Dispatchers.IO 的“双刃剑”
为何只有 8 个任务，线程数却直接翻倍？答案藏在 Kotlin 协程默认调度器的实现细节中。
Dispatchers.IO 底层的线程池是一个无界（实际最大 64）的经典线程池，其核心线程数为 0，最大线程数则为 64。当任务到达时，线程池会创建新线程来执行，直到达到上限。这意味着，8 个并发协程会立刻获得 8 个单独的 IO 线程。加上 App 原有的 8 个非协程线程（主线程、渲染线程、垃圾回收线程等），总线程数自然从 8 变为 16。
更关键的是，如果协程内部调用的是真正的阻塞式操作（如 Thread.sleep 或阻塞 I/O），该线程会被完全占用而无法释放。此时即使协程挂起，线程本身并不会归还到池中——它会一直等待阻塞调用结束。这导致线程池必须不断创建新线程来处理后续任务，进一步加剧资源消耗。
专家观点： 阿里资深技术专家李明峰指出：“很多开发者误以为协程就是线程，实际上协程是轻量的控制流，而调度器才是真正的线程分配者。Dispatchers.IO 的存在是为了绕过阻塞，但若滥用，反而会制造出比原始线程模型更多的线程，违背协程设计的初衷。”
场景放大：一个协程中嵌套多个 withContext
问题还不止于此。如果每个异步任务内部又嵌套了多次 withContext(Dispatchers.IO) 切换，情况会更糟。假设一个任务中连续三次调用阻塞式 I/O，那么每个 withContext 都会从 IO 线程池中申请一个新线程。8 个任务 × 3 次切换，瞬间就会产生 24 个 IO 线程，加上原有线程，总数可能突破 30。而开发者眼中的“只有 8 个任务”，在系统层面早已演变成一场线程洪灾。
排查与反思：如何避免线程数失控
这一现象在 Android 开发和后端服务中并不罕见。解决方案并非禁用协程，而是合理配置调度器：
-
使用
limitedParallelism限制并发数
Dispatchers.IO.limitedParallelism(8)可将 IO 线程池峰值锁定为 8，避免无限扩张。 -
避免在协程中使用原生阻塞 API
多数现代库已提供挂起版本（如 Ktor、OkHttp 的挂起支持），优先使用它们可让线程在等待时被回收复用。 -
区分 CPU 密集与 IO 密集任务
Dispatchers.Default适合计算密集型操作，其线程数受限于 CPU 核心数，不会盲目增长。
结语：协程很轻，调度器不轻
协程的“轻量”体现在挂起与恢复的低开销，而非线程本身。Dispatchers.IO 的设计初衷是解决阻塞 I/O 场景下的线程复用问题，但它的“懒创建”机制恰恰是线程数突发增长的根源。当开发者仅关注协程的数量而忽略调度器的行为时，便会出现“8 个任务、16 个线程”这样看似矛盾的统计结果。
在性能敏感的应用中，对协程调度器的理解与配置，应和协程本身一样受到重视。毕竟，线程池的每一根线，都连着系统资源的真实消耗。