协程模式：从回调地狱到结构化并发的进化之路

协程这个概念，说实话我接触得比较晚。早年在C++里做游戏服务器，用的都是传统的线程池加回调。直到有一次项目里回调嵌套了七八层，调试到凌晨三点，我才真正意识到——我们需要一种更优雅的并发模型。

协程模式，说白了就是让函数可以暂停、挂起，然后在合适的时候恢复执行。它不像线程那样依赖操作系统调度，而是由程序自己控制。嗯，这里要注意：协程不是银弹，但它在某些场景下确实能大幅简化代码。

协程的核心机制：挂起与恢复

我习惯把协程理解成「可以暂停的函数」。普通函数一旦调用，就必须从头执行到尾。但协程可以在中间某个点停下来，把控制权交出去，等条件满足了再回来继续跑。

关键区别：线程的切换由操作系统内核完成，开销大；协程的切换由用户态程序完成，开销极小。

来看一个简单的Java虚拟线程示例：

// Java 21 虚拟线程示例
public class VirtualThreadDemo {
    public static void main(String[] args) throws Exception {
        Thread.startVirtualThread(() -> {
            System.out.println("协程开始: " + Thread.currentThread());
            // 这里会挂起，但不阻塞底层操作系统线程
            sleep(1000);
            System.out.println("协程恢复: " + Thread.currentThread());
        }).join();
    }
    
    static void sleep(long millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

你想想看，这段代码里 Thread.sleep() 的时候，底层操作系统线程并没有被阻塞。虚拟线程被挂起了，等时间到了再恢复。这就是协程的挂起与恢复机制。

协程调度：谁来决定下一个跑谁？

协程调度器负责决定「当前挂起的协程，什么时候恢复，哪个协程先跑」。我个人习惯把调度策略分为两类：

调度策略 特点 适用场景
协作式调度 协程主动让出CPU，自己决定何时挂起 Kotlin协程、Lua协程
抢占式调度 调度器强制切换，协程无法控制 Java虚拟线程（底层由ForkJoinPool管理）

我在项目中遇到过一个问题：用Kotlin协程做爬虫，某个协程里写了死循环，结果整个调度器都卡住了。这就是协作式调度的风险——协程必须主动配合，否则调度器拿它没办法。

避坑指南：我曾经在Kotlin协程里忘记加 yield() 调用，导致一个计算密集型的协程霸占了线程，其他协程饿死。后来我养成了习惯：在长循环里显式调用 yield() 或 delay(0)。

结构化并发：让协程不再「野」

结构化并发是我认为协程模式里最重要的设计思想。它解决了一个老问题：线程一旦启动，就像脱缰的野马，你很难控制它的生命周期。

结构化并发的核心原则：

  • 生命周期绑定：协程的生命周期不能超过它的父作用域
  • 错误传播：子协程抛出异常，父协程能感知并处理
  • 自动取消：父作用域结束，所有子协程自动取消

来看Kotlin的结构化并发示例：

// Kotlin 结构化并发
suspend fun fetchUserData(): UserData = coroutineScope {
    // 这两个协程并行执行，但生命周期绑定在coroutineScope内
    val user = async { loadUser() }
    val posts = async { loadPosts() }
    
    // 如果任何一个async抛出异常，整个scope都会取消
    UserData(user.await(), posts.await())
}

你想想看，如果没有结构化并发，loadUser() 和 loadPosts() 启动的协程就成了「野协程」。即使调用方已经退出，它们还在后台偷偷跑着。结构化并发强制你管理好协程的边界。

Kotlin协程 vs Java虚拟线程：我该怎么选？

这两个东西经常被拿来比较。我个人的经验是：它们解决的是类似的问题，但设计哲学不同。

维度 Kotlin协程 Java虚拟线程
语言支持 库级别，需要引入kotlinx.coroutines JVM原生支持，Java 21+
挂起机制 suspend关键字，编译器生成状态机 JVM层面自动处理，对开发者透明
结构化并发 原生支持，coroutineScope、supervisorScope 需要手动管理，或借助第三方库
适用场景 Android、后端服务、响应式编程 高并发IO密集型服务、微服务

我记得有一次帮团队做技术选型，最后选了Kotlin协程。原因很简单：团队里大部分是Android开发，对Kotlin更熟悉。如果你们团队是纯Java栈，那虚拟线程上手更快。

我的建议：别纠结「哪个更好」。Kotlin协程在结构化并发和错误处理上更成熟，Java虚拟线程在透明性和与现有代码的兼容性上占优。根据团队背景和项目需求选就行。

协程模式的核心知识体系

下面这张图是我自己总结的协程模式知识结构，方便你快速建立整体认知：

协程模式 挂起与恢复 协程调度 结构化并发 状态机生成 非阻塞挂起 协作式 vs 抢占式 ForkJoinPool 生命周期绑定 错误传播与取消 Kotlin协程 / Java虚拟线程

实战中的避坑经验

最后分享几个我踩过的坑：

  • 不要在协程里做阻塞IO： 我曾经在Kotlin协程里直接调了 Thread.sleep()，结果整个调度器线程被阻塞。应该用 delay() 或者把阻塞操作放到 withContext(Dispatchers.IO) 里。
  • 注意协程的取消是协作式的： 虚拟线程和Kotlin协程都不会强制中断正在执行的代码。如果你的协程在计算密集的循环里，记得检查 isActive 或 Thread.interrupted()。
  • 结构化并发不是银弹： 它强制你管理协程的生命周期，但如果你不小心创建了全局作用域（比如 GlobalScope），那又回到了「野协程」的老路上。

协程模式的核心价值，说白了就是让异步代码看起来像同步代码，同时把并发控制权交还给开发者。不管是Kotlin协程还是Java虚拟线程，背后的思想都是相通的。嗯，希望这些经验能帮你少走一些弯路。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →