《游戏服务端编程实践》2.1.3 多线程与协程的差异

一、引言：从线程到协程的时代转折

在计算机的早期时代，程序通常是顺序执行的：一条指令执行完才开始下一条。 当网络 I/O、磁盘读写、数据库访问等耗时操作出现后，顺序模型的 CPU 利用率变得极低。于是人们发明了：

• 多进程（Multi-Process） —— 每个任务独立运行；
• 多线程（Multi-Thread） —— 在一个进程内并发执行多个任务；
• 异步回调（Asynchronous Callback） —— 通过事件驱动减少阻塞；
• 协程（Coroutine） —— 用户态轻量线程，进一步提升并发效率。

从工程角度来看：

线程是系统提供的并发单元，协程是语言运行时提供的并发抽象。

现代高并发后端（如 Go、Rust、Kotlin、Lua、Python asyncio）几乎都采用协程模型。 而游戏服务器正是这种转变的最佳舞台：需要高并发、低延迟、状态隔离且逻辑可控。

二、基本定义

线程由操作系统调度； 协程由程序自己调度。

三、线程模型回顾

3.1 操作系统线程（OS Thread）

每个线程拥有：

• 独立的调用栈（stack）；
• 寄存器上下文；
• 内核调度状态。

当 CPU 需要在多个线程间切换时：

1. 保存当前线程的上下文；
2. 加载目标线程的上下文；
3. 更新页表、寄存器；
4. 切换至新线程运行。

这就是上下文切换（Context Switch）。

3.2 多线程服务器模型

典型形态：一个连接一个线程 或 线程池复用线程处理任务。

ExecutorService pool = Executors.newFixedThreadPool(8);
while (true) {
    Socket client = server.accept();
    pool.submit(() -> handle(client));
}

优点：

• 代码同步、逻辑清晰；
• 每个任务独立，不干扰；
• 利用多核 CPU。

缺点：

• 每个线程约消耗 1~2MB 栈空间；
• 创建/销毁线程昂贵；
• 大量上下文切换；
• 调度由内核决定，不可控；
• 难以在高并发（10w+连接）下扩展。

四、协程模型的引入

4.1 协程的核心思想

“让程序自己决定什么时候切换上下文，而不是交给操作系统。”

协程运行在用户态：

• 拥有独立的栈和上下文；
• 但切换时只保存少量寄存器；
• 不需要陷入内核；
• 开销极小（通常为 100ns 级别）。

4.2 协程的关键特性

4.3 伪代码对比

线程模型（阻塞）

String data = socket.read();  // 阻塞等待
process(data);

协程模型（异步同步化）

data := await socket.Read()   // 挂起，不阻塞线程
process(data)

结果看起来一样，但背后的调度完全不同。 在协程模型中，Read() 会挂起当前协程，把 CPU 让给其他协程；当数据就绪时再恢复执行。

五、线程与协程的调度机制差异

5.1 线程调度：由内核完成

• 操作系统负责决定哪个线程运行；
• 调度粒度：时间片（10~20ms）；
• 使用系统调用（syscall）切换；
• 上下文切换成本高（保存寄存器 + TLB flush + 栈切换）。

5.2 协程调度：由语言运行时完成

• 用户态函数调用；
• 调度粒度更细（函数级或 I/O 事件级）；
• 切换开销低（几十纳秒）；
• 可根据业务逻辑自定义策略。

5.3 调度模型分类

现代语言基本都采用 M:N 模型。

六、Go 的协程模型（GMP）

Go 是现代协程设计的经典代表。

6.1 调度结构

关系示意：

graph LR
G1["Goroutine 1"] --> P1["P1"]
G2["Goroutine 2"] --> P1
G3["Goroutine 3"] --> P2["P2"]
P1 --> M1["Thread 1"]
P2 --> M2["Thread 2"]

• Go runtime 动态将 G 分配到 P；
• P 绑定 M 执行；
• I/O 挂起时，G 被移出队列；
• 线程继续执行其他 G。

6.2 优点

• 高效 M:N 调度；
• 自动负载均衡；
• 无需开发者显式调度；
• 支持数百万并发。

七、Java Loom 的虚拟线程（Virtual Thread）

Java 在 2023 正式引入虚拟线程（Project Loom）， 本质上是 Java 自带协程实现。

Thread.startVirtualThread(() -> {
    var data = socket.read();
    process(data);
});

底层实现：

• 每个虚拟线程挂起时，脱离操作系统线程；
• 由 JDK 的 ForkJoinScheduler 调度；
• 栈帧保存在堆上；
• 切换成本接近 Go 协程。

Loom 使得 Java 的并发编程方式彻底改变——

“以同步的写法编写异步的系统。”

八、协程的挂起与恢复机制

8.1 栈保存原理

协程可以在任意位置挂起执行，通过保存：

• 栈指针（SP）；
• 寄存器；
• 程序计数器（PC）。

在恢复时重新加载这些状态即可继续执行。

8.2 挂起触发点

• 网络 I/O；
• 等待锁；
• Channel 收发；
• 定时器；
• 显式 yield。

func worker(ch chan int) {
    for v := range ch {
        fmt.Println(v)
        runtime.Gosched()  // yield
    }
}

九、内存与上下文切换成本对比

十、协程与 Reactor 的关系

Reactor 关注“事件”，协程关注“执行”； Reactor 解决“谁先响应”；协程解决“谁先执行完”。

十一、协程中的通信：Channel 模式

Go、Rust、Kotlin 等协程模型中，线程间通信不依赖共享内存，而通过 Channel（消息通道）：

func producer(ch chan int) {
    for i := 0; i < 10; i++ {
        ch <- i
    }
}

func consumer(ch chan int) {
    for v := range ch {
        fmt.Println("consume:", v)
    }
}

优点：

• 无锁；
• 自动阻塞/唤醒；
• 天然符合 CSP 模型（Communicating Sequential Processes）。

这也是游戏逻辑层消息调度的理想模式。

十二、协程在游戏服务器中的优势

在 SLG 或 MMO 游戏中：

• 每个战斗房间一个协程；
• 每个玩家任务一个协程；
• 跨模块通信通过 Channel；
• 极大简化锁与共享状态管理。

十三、线程池 vs 协程调度器

十四、线程安全与同步模型对比

十五、协程调度策略

1. 协作式调度（Cooperative）

   • 协程主动 yield；
   • 常见于 Lua、Python、C# async；
   • 不抢占，安全但可能“饿死”其他任务。

2. 抢占式调度（Preemptive）

   • 运行时定期中断；
   • 常见于 Go；
   • 防止单协程长期占用 CPU。

3. 混合调度

   • 可在 IO 等待、时间片、系统事件时自动切换；
   • 实现最复杂，但体验最好。

十六、协程的局限性与陷阱

十七、混合模型：线程 + 协程

实际工程中往往混合使用：

• 每核运行一个 I/O 线程；
• 在线程内运行数千协程；
• 协程之间使用 Channel；
• 线程间通过消息总线通信。

// 简化版模型
func main() {
    for i := 0; i < runtime.NumCPU(); i++ {
        go reactor()
    }
}

func reactor() {
    for event := range netpoll() {
        go handle(event)
    }
}

这是现代分布式游戏服务器（如 Skynet、Go + Akka 混合架构）的主流模式。

十八、语言层面对比

十九、工程实战建议

二十、思考题与实践

1. 为什么线程上下文切换代价比协程高几个数量级？
2. Go 如何实现 M:N 调度？
3. Java Loom 的虚拟线程如何节省内存？
4. 在游戏中，每个玩家是否都该用一个协程？为什么？
5. 协程调度中如何防止“饿死”？

二十一、小结

多线程是并发的起点，协程是并发的未来。

结语：

线程模型让程序能“同时做很多事”， 协程模型让程序能“以同步方式并发做很多事”。

协程并不是“更小的线程”， 而是一种更聪明的并发抽象 —— 它让“复杂的异步系统”重新变得“看起来像同步的代码”。

• Game Server
• Game
• Game in Action
• Programming