四种协程调度器

核心规则：线程数 = CPU 核心数（最少 2 个）。例如 8 核手机就是 8 个线程。

要理解这个设计，先要想清楚 CPU 密集型任务的特征：

• 一个任务持续占用 CPU 直到完成，几乎不会主动让出 CPU
• 任务之间没有"等待 I/O"的空隙可钻

假设你有一台 8 核机器：

如果你在 Dispatchers.Default里执行阻塞 I/O（如 InputStream.read()、同步网络请求），会发生什么？

//  错误示范：在 Default 上做阻塞 I/O
launch(Dispatchers.Default) {
    val socket = Socket("example.com", 80)
    val reader = BufferedReader(InputStreamReader(socket.getInputStream()))
    val line = reader.readLine()  // ← 阻塞！这个 Default 线程被占住，其他计算任务没线程可用
}

//  正确做法：I/O 操作交给 Dispatchers.IO
launch(Dispatchers.IO) {
    val socket = Socket("example.com", 80)
    val reader = BufferedReader(InputStreamReader(socket.getInputStream()))
    val line = reader.readLine()  // IO 调度器有弹性线程池，不怕阻塞
}

为了直观感受为什么 Default 上不能做阻塞 I/O，我们来做一个具体的场景推演。假设 8 核机器，Default 线程池有 8 个线程，同时启动 20 个协程：

核心规则：按需创建和回收线程，默认上限 64 个（可通过 kotlinx.coroutines.scheduler.max.pool.size配置）。

I/O 任务的特征与 CPU 任务截然不同：

• I/O 任务经常阻塞：等网络响应、等磁盘寻道、等数据库返回
• 当一个线程被 I/O 阻塞时，它让出 CPU，CPU 核心就闲着了
• 如果只有核数个线程，一旦有几个线程阻塞在 I/O 上，CPU 就开始摸鱼

这就是 IO 调度器需要弹性线程池的根本原因：

IO 调度器可以临时创建新线程去执行其他就绪的协程，从而保证 CPU 一直有活干。同时为了防止内存耗尽和过度竞争，线程数量设置了 64 的上限。

把这个设计想象成一家餐厅：Default 是"厨师"——有几个灶台（CPU 核心）就配几个厨师，刚好满负荷。而 IO 是"服务员"——服务员经常等在厨房门口（阻塞等菜），如果只有 3 个服务员，客人多了就忙不过来。所以餐厅会临时多叫几个服务员（弹性扩容），保证每个灶台始终有人对接，但也不可能无限叫（64 上限），否则餐厅挤满服务员反而乱了。

理解 IO 调度器的设计，必须区分两种完全不同的"等待"。先看一段对比代码，直观感受二者的差异：

// 挂起函数：底层是非阻塞 NIO + 协程挂起
suspend fun fetchWithKtor(): String {
    val client = HttpClient(CIO) {
        engine { requestTimeout = 5_000 }
    }
    return client.get("https://api.example.com/data").body()
}

// 执行过程：
// 1. 协程在线程 A 发起 HTTP 请求
// 2. 网络 I/O 注册到 NIO Selector → 协程挂起（不阻塞线程！）
// 3. 线程 A 立刻被释放，去执行另一个协程
// 4. 网络数据到达 → Selector 通知 → 线程 B 恢复协程
// 5. 全程没有任何线程被阻塞在原地等待

// 阻塞 I/O：Java 原生 Socket，线程直接卡死
fun fetchWithBlockingSocket(): String {
    val socket = Socket("api.example.com", 80)
    val writer = OutputStreamWriter(socket.outputStream)
    val reader = BufferedReader(InputStreamReader(socket.inputStream))

    writer.write("GET /data HTTP/1.1\r\nHost: api.example.com\r\n\r\n")
    writer.flush()

    val line = reader.readLine()  // ← 线程在此阻塞！啥也干不了
    //  操作系统直接把当前线程挂起 (BLOCKED 状态)
    //  直到网络数据到达，线程才被唤醒
    return line
}

// 如果这个函数跑在 Dispatchers.Default 上 → 灾难
// 如果跑在 Dispatchers.IO 上 → 没问题，IO 有弹性线程补位

//  典型用法：挂起 API + 必要时才用阻塞操作
launch(Dispatchers.IO) {
    //  挂起函数：底层是非阻塞异步 I/O，线程不等待
    val response = httpClient.get("https://api.example.com/data")

    //  文件 I/O：Kotlin 的 writeText 内部依然是阻塞的，放在 IO 线程
    val file = File(context.cacheDir, "cache.json")
    file.writeText(response.body)

    // Room 数据库：内部用挂起函数包装，实际仍是阻塞 SQLite 操作
    val dao = database.userDao()
    val users = dao.getAllUsers()

    // 切回主线程更新 UI
    withContext(Dispatchers.Main) {
        textView.text = "加载完成：${users.size} 个用户"
    }
}

在 Android 上，Dispatchers.Main依赖 Looper.getMainLooper()和 Handler来投递任务。这和 View.post()思路一致——都是往主线程的消息队列里塞任务——但 Dispatchers.Main 是立即执行的优先级。

// 如果你在子线程中调用 withContext(Dispatchers.Main)
launch(Dispatchers.IO) {
    val data = fetchDataFromNetwork()     // 在 IO 线程

    withContext(Dispatchers.Main) {       // 协程挂起 →
        // 框架通过 Handler 将恢复执行的部分切回主线程
        textView.text = data              // 安全更新 UI
    }  // ← 执行完自动回到 IO 线程
}

结合 lifecycleScope或 viewModelScope，协程自动绑定了 Main 调度器，界面相关代码默认就运行在主线程，简洁且安全。

这是一个非常容易被忽略的细节，但在性能敏感场景下很关键。先看一段对比代码：

// 假设当前已在主线程执行
fun onButtonClick() {  // ← 在主线程
    launch(Dispatchers.Main) {
        println("A")  // 不会立即执行！
    }
    println("B")
}
// 输出顺序：B → A

// 原因：Dispatchers.Main 无条件调用：
// handler.post { /* 整个协程代码块 */ }
// 相当于把"打印A"塞到消息队列末尾
// 必须先等当前消息（打印B）执行完

// 假设当前已在主线程执行
fun onButtonClick() {  // ← 在主线程
    launch(Dispatchers.Main.immediate) {
        println("A")  // 立即同步执行！
    }
    println("B")
}
// 输出顺序：A → B

// 原因：Main.immediate 的执行逻辑：
// if (Looper.myLooper() == Looper.getMainLooper()) {
//     直接执行代码块  // ← 当前就在主线程，跳过 Handler
// } else {
//     handler.post { /* 代码块 */ }  // ← 不在主线程才投递
// }

Dispatchers.Unconfined不会把协程限定在任何特定线程上。协程在挂起点恢复后，会运行在刚好触发恢复的那个线程里，而不进行线程切换。

launch(Dispatchers.Unconfined) {
    println("第一次打印：${Thread.currentThread().name}")
    // ↑ 在 launch 调用的线程上执行（比如主线程）

    delay(100)
    // ↑ 挂起！协程离开所有线程

    println("第二次打印：${Thread.currentThread().name}")
    // ↑ 恢复时在 delay 定时器回调的线程上执行
    //   delay 的内部定时器回调在 kotlinx.coroutines.DefaultExecutor 的线程上
    //   所以第二次打印可能输出完全不同的线程名！
}

Unconfined 的核心特征：协程在哪个线程被恢复，就在哪个线程继续执行。恢复线程取决于"是谁触发了挂起点的回调"——这完全不可预测。

恢复线程的几种常见来源：

假设你在 Activity 中写了这样一段代码——这在业务开发中看起来"好像也对"：

//  危险代码：Unconfined + UI 操作 = 随机崩溃
class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        lifecycleScope.launch(Dispatchers.Unconfined) {
            // 第一次执行：在 Main 线程（因为 launch 调用者在 Main）
            val data = fetchData()  // suspend 函数

            // ⚠️ 你以为还在主线程？不一定！
            // fetchData() 内部如果用了 withContext(IO)，
            // 恢复时可能飘到 IO 线程池的某个线程上！
            textView.text = data  // → CalledFromWrongThreadException !!!
        }
    }
}

这个崩溃不是每次必现，它取决于 fetchData()内部实现、网络延迟、线程池状态——可能开发阶段从不 crash，上线后用户量大时随机崩溃。这就是 Unconfined 最阴险的地方。

Unconfined 会带来三类严重问题：

Unconfined 仅在以下场景有存在价值（且这些场景都不是业务代码该碰的）：

• 编写自定义协程构建器：需要实现"继承调用者上下文"的行为时
• 底层库开发：某些极轻量的非阻塞操作，希望避免线程切换的开销
• 测试代码：有时为了精确控制执行顺序

这就是协程调度器的精妙之处：同一个底层线程池，Default 克制地只用核数个线程追求 CPU 效率，IO 弹性地扩展线程数填补 I/O 空隙。两者各司其职，共享基础设施却行为迥异。