1 缘起
在软件世界里，性能与并发始终是绕不开的主题。从最早的操作系统线程，到语言层的协程，再到更轻量的纤程，以及近年来备受关注的虚拟线程，每一次抽象层级的提升，都是为了让程序能以更低的成本、更高的效率处理更多任务。随着硬件发展放缓、应用规模不断扩大，我们不再单纯依赖"更快的 CPU"，而是必须学会更聪明地使用计算资源。理解线程、协程、纤程与虚拟线程的演进，不只是掌握几个名词，而是看清现代并发模型背后的设计哲学：如何在复杂性、性能与开发体验之间找到平衡。也正因此，重新梳理这些概念，成为每一个开发者迈向更高层次并发编程的必经之路。
2 内容角度
- 概念
- 调度方式
- 上下文切换
- 栈模型
- 存在问题及解决方案
3 概念
3.1 一句话概念
-
线程：OS 调度的最小执行单元
-
协程：用户态调度的轻量执行单元
-
纤程：协程的一种底层实现方式（用户态栈切换）
-
虚拟线程：JVM 提供的轻量线程（语义是线程，性能像协程）
3.2 概念详解
3.2.1 线程
- 线程运行在内核态，由操作系统负责调度（抢占式）。
- 多个线程共享同一进程的内存空间，但每个线程有独立的栈。
- 创建成本高、切换成本高（需要内核态切换）。
- 适合 CPU 密集型任务。
3.2.2 协程
- 不由操作系统调度，而是由语言运行时或框架调度（协作式）。
- 切换不需要进入内核态 → 成本极低（纳秒级）。
- 栈空间小（KB 级），可支持百万级并发。
- 适合 I/O 密集型任务（如网络请求、爬虫、服务端高并发）。
3.2.3 纤程
- 纤程是协程的一种更底层的形式，强调"用户态栈切换"。
- 切换时保存/恢复寄存器、栈指针等，不进入内核。
- 需要开发者或运行时显式让出执行权（协作式）。
- 常见于 C++、游戏引擎、Boost Fiber 等。
3.2.4 虚拟线程
- 虚拟线程不是 OS 线程，而是 JVM 内部结构。
- JVM 会把虚拟线程挂在少量 OS 线程上执行（类似 M:N 模型）。
- 阻塞不会占用 OS 线程（JVM 会自动挂起虚拟线程）。
- 创建成本极低，可支持百万级并发。
- 适合 Java 服务端高并发场景（Web 服务、数据库访问）。
3.2.5 对比
| 特性 | 线程 | 协程 | 纤程 | 虚拟线程 |
|---|---|---|---|---|
| 调度者 | OS | 用户态 | 用户态 | JVM |
| 调度方式 | 抢占式 | 协作式 | 协作式 | 混合式 |
| 切换成本 | 高 | 极低 | 极低 | 极低 |
| 栈大小 | MB | KB | KB | KB（分段） |
| 并发数量 | 万级 | 百万级 | 百万级 | 百万级 |
| 阻塞行为 | 占用 OS 线程 | 需非阻塞 I/O | 需非阻塞 I/O | 不占用 OS 线程 |
| 典型语言 | C++/Java | Go/Python/Kotlin | C++/系统库 | Java Loom |
4 调度方式
4.1 线程
- 调度者：操作系统内核（Kernel Scheduler）
- 调度方式：抢占式调度（Preemptive Scheduling）
（1）OS 会根据时间片、优先级等策略强制切换线程
（2）线程不需要主动让出 CPU
（3）切换时必须进入内核态，保存/恢复寄存器、栈指针等 - 特点
（1）公平性强：不会因为某个线程不让出 CPU 而卡死
（2）成本高：内核态切换开销大（微秒级）
（3）适合 CPU 密集型任务
4.2 协程
- 调度者：用户态运行时（Runtime / Event Loop）
- 调度方式：协作式调度（Cooperative Scheduling）
（1）协程必须 主动让出执行权（如 await、yield）
（2）调度器在用户态切换协程，不进入内核态
（3）切换只需保存少量寄存器和栈指针 - 特点
（1）切换成本极低（纳秒级）
（2）不公平：如果协程不让出，会阻塞整个调度器
（3）适合 I/O 密集型任务
4.3 纤程
- 调度者：用户态（通常由库或框架）
- 调度方式：协作式调度（Cooperative）
（1）纤程本质上是协程的一种底层实现，因此调度方式类似：
（2）完全用户态
（3）手动切换栈（保存/恢复寄存器、指令指针、栈指针）
（4）必须主动让出执行权 - 特点
（1）比协程更底层
（2）切换成本极低
（3）常用于 C++、游戏引擎、Boost Fiber 等
4.4 虚拟线程
- 调度者：JVM（而不是 OS）
- 调度方式：混合式调度（Cooperative + OS Scheduling）
虚拟线程的调度方式非常独特：
（1） 运行时由 JVM 调度（类似协程）虚拟线程不是 OS 线程，JVM 会把大量虚拟线程挂在少量 OS 线程上执行（M:N 模型）。
（2）阻塞时自动挂起（协作式）
当虚拟线程执行阻塞 I/O，JVM 会自动把它挂起，不占用 OS 线程，I/O 完成后再恢复。
（3）最终仍由 OS 调度底层载体线程（抢占式）虚拟线程运行在 OS 线程上，OS 线程仍然是抢占式调度。 - 特点
（1）语义是线程，性能像协程
（2）阻塞不会占用 OS 线程
（3）适合 Java 高并发服务
4.5 对比
| 模型 | 调度者 | 调度方式 | 是否抢占 | 是否进入内核态 | 切换成本 |
|---|---|---|---|---|---|
| 线程 | OS | 抢占式 | 是 | 是 | 高（微秒） |
| 协程 | 用户态 | runtime | 协作式 | 否 | 否 |
| 纤程 | 用户态 | 协作式 | 否 | 否 | 极低（纳秒） |
| 虚拟线程 | JVM | 混合式（协作 + 抢占） | 部分 | 阻塞时否 | 极低 |
5 上下文切换
5.1 线程
-
切换发生位置：内核态（Kernel Mode）
-
切换内容（非常多）
线程切换时，操作系统需要保存和恢复：
- 寄存器（通用寄存器、程序计数器 PC）
- 栈指针（SP）
- 内核栈
- CPU 状态字
- 内存管理信息（如页表）
- 调度器元数据（优先级、时间片等）
-
切换过程
（1）OS 抢占当前线程
（2）保存当前线程上下文到内核
（3）加载另一个线程的上下文
（4）切回用户态继续执行
-
特点
（1）必须进入内核态 → 成本高（微秒级）
（2）切换内容多
（3）线程栈大（MB），切换时需要更多维护
5.2 协程
-
切换发生位置：用户态（User Mode）
-
切换内容（非常少）
协程切换只需保存：
- 少量寄存器（如 PC、SP）
- 协程栈指针
- 协程局部状态（由 runtime 管理）
-
切换过程
（1）协程主动让出（await / yield）
（2）runtime 保存当前协程的寄存器和栈指针
（3）runtime 恢复另一个协程的寄存器和栈指针
（4）继续执行
-
特点
（1）不进入内核态 → 成本极低（纳秒级）
（2）切换内容少
（3）栈小（KB），切换轻量
5.3 纤程
-
切换发生位置：用户态
-
纤程是协程的底层实现，因此切换方式类似，但更底层。
切换内容
- 保存/恢复寄存器
- 保存/恢复指令指针（IP）
- 保存/恢复栈指针（SP）
- 切换用户态栈（纤程有独立栈）
-
切换过程
（1）纤程切换通常通过 手动切换栈 完成，例如：
（2）保存当前栈指针
（3）切换到另一个纤程的栈
（4）恢复寄存器
（5）跳转到新纤程的执行点
-
特点
（1）完全用户态 → 不进入内核
（2）切换成本与协程相当（纳秒级）
（3）更接近底层，常用于 C++、游戏引擎
5.4 虚拟线程
-
切换发生位置：JVM 内部（用户态 + 少量内核态）
-
虚拟线程的切换方式最特别，因为它结合了线程语义和协程性能。
-
两种切换场景
（1） 虚拟线程之间的切换（用户态）
当虚拟线程主动挂起（如 I/O 阻塞）时：
- JVM 保存虚拟线程的栈帧（分段栈）
- JVM 切换到另一个虚拟线程
- 类似协程切换 → 不进入内核态
（2）虚拟线程绑定的 OS 线程切换（内核态）
虚拟线程最终运行在 OS 线程上，因此：
- OS 线程之间的切换仍然是内核态
- 但虚拟线程数量远大于 OS 线程数量
- 大部分切换发生在 JVM 内部，而不是 OS
-
特点
（1）阻塞不会占用 OS 线程（JVM 会自动挂起虚拟线程）
（2）大部分切换在 JVM 内部 → 成本接近协程
（3）保留线程语义（同步代码也能高并发）
5.5 对比
| 模型 | 切换位置 | 是否进入内核态 | 切换成本 | 切换内容 | 本质 |
|---|---|---|---|---|---|
| 线程 | 内核态 | 是 | 高（微秒） | 寄存器 + 栈 + 内核状态 | OS 调度 |
| 协程 | 用户态 | 否 | 极低（纳秒） | 寄存器 + 栈指针 | 用户态调度 |
| 纤程 | 用户态 | 否 | 极低（纳秒） | 寄存器 + 栈切换 | 协程底层实现 |
| 虚拟线程 | JVM 内部 + 少量内核 | 部分 | 低 | 分段栈 + JVM 状态 | JVM 版协程 |
6 栈模型
6.1 线程
-
栈大小：固定且大（通常 1MB 左右）
每个线程创建时，OS 会为它分配一个 固定大小的大栈（如 1MB、2MB）。
栈空间一旦分配，不能动态缩小。
-
栈结构
（1）调用栈（函数调用帧）
（2）局部变量
（3）返回地址
（4）异常处理信息
-
特点
（1）占用内存大 → 限制线程数量（一般几千到几万）
（2）切换成本高 → 栈大，切换时需要更多状态维护
（3）适合 CPU 密集型任务
6.2 协程
-
栈大小：小且可动态扩容（几 KB 起）
协程的栈通常只有 几 KB，并且可以按需增长。
例如：
Go goroutine：初始栈 2KB，可动态扩容
Kotlin 协程：栈分段 + continuation 保存状态
Python asyncio：状态保存在对象中，不依赖传统栈
-
栈结构
协程的栈通常是：
（1）小栈（stacklet）
（2）分段栈（segmented stack）
（3）或状态机（async/await 转换）
-
特点
（1）占用内存极小 → 可创建百万协程
（2）切换成本低 → 栈小，切换轻量
（3）适合 I/O 密集型任务
6.3 纤程
-
栈大小：小栈（KB 级），独立栈，手动切换
纤程是协程的底层实现，因此栈模型类似协程，但更底层。
-
栈结构
（1）每个纤程有独立的用户态栈
（2）栈大小通常在 KB 级
（3）切换时需要手动保存/恢复栈指针（SP）
-
特点
（1）完全用户态栈
（2）切换时直接切换栈指针
（3）比协程更底层、更灵活
-
常见于：
（1）C++ Boost Fiber
（2）Windows Fiber API
（3）游戏引擎任务系统
6.4 虚拟线程
-
栈大小：小栈 + 分段栈（Stack Chunking）
虚拟线程的栈不是一次性分配，而是 按需分段分配。
类似协程的分段栈模型。
-
栈结构
（1）栈被拆成多个小块（chunk）
（2）JVM 会在挂起虚拟线程时把栈帧"拆开"并存储到堆中
（3）恢复时再重新组装
-
特点
（1）初始栈很小 → 可创建百万虚拟线程
（2）阻塞时栈会被挂起到堆中 → 不占用 OS 线程
（3）保留线程语义 → 同步代码也能高并发
6.5 对比
| 模型 | 栈大小 | 是否可扩容 | 栈位置 | 切换成本 | 并发能力 |
|---|---|---|---|---|---|
| 线程 | MB 级 | 否 | OS 分配 | 高 | 万级 |
| 协程 | KB 级 | 是 | 用户态 | 极低 | 百万级 |
| 纤程 | KB 级 | 是 | 用户态 | 极低 | 百万级 |
| 虚拟线程 | KB 级（分段） | 是 | JVM 管理 | 低 | 百万级 |
7 应用场景
7.1 实际场景
-
CPU 密集型
线程（或线程池）
-
I/O 密集型
→ 协程 / 纤程 / 虚拟线程
-
Java 高并发服务
虚拟线程（Loom）
7.2 编程语言实现
Go：goroutine（协程） + M:N 调度
Python：asyncio 协程
Java：传统线程池 → 虚拟线程（Loom）
C++：Boost Fiber / C++20 coroutine
Rust：async/await + executor
8 常见问题
8.1 线程
8.1.1 问题1：线程数量受限（无法支持高并发）
- 原因：
每个线程占用 1MB 左右栈空间
OS 调度成本高
创建/销毁成本大 - 解决：
使用线程池（Thread Pool）
控制最大线程数
使用异步 I/O 或协程替代
8.1.2 问题 2：线程上下文切换开销大
-
原因：
切换需要进入内核态
保存/恢复大量寄存器、栈、调度信息
-
解决：
减少线程数量
使用无锁结构、减少竞争
使用协程/虚拟线程替代
8.1.3 问题 3：线程泄漏（Thread Leak）
- 表现：
线程不断创建但不退出，导致系统资源耗尽。 - 原因：
线程未正确结束
死循环
阻塞 I/O
未关闭线程池 - 解决：
使用线程池统一管理
设置超时机制
避免无限阻塞
监控线程数量
8.2 协程
8.2.1 问题 1：协程泄漏（Coroutine Leak）
-
表现：
协程数量不断增加，最终 OOM。
-
原因：
协程未正确结束
异步任务未 await
无限挂起（suspend forever）
忘记取消协程（如 Kotlin 的 Job）
-
解决：
使用结构化并发（structured concurrency）
设置超时（timeout）
必须 await 或 cancel
使用协程作用域（scope）管理生命周期
8.2.2 问题 2：协程阻塞导致整个调度器卡死
- 原因：
协程是协作式调度，如果一个协程执行阻塞操作（如 sleep、IO），会阻塞整个事件循环。 - 解决：
使用非阻塞 I/O
在专用线程池执行阻塞任务（如 Kotlin 的 Dispatchers.IO）
使用 async/await 正确让出执行权
8.2.3 问题 3：协程调度不公平
- 原因：
协作式调度依赖协程主动让出，如果某个协程不让出，会饿死其他协程。 - 解决：
避免长时间 CPU 计算
使用 yield
将 CPU 密集型任务放入线程池
8.3 纤程
8.3.1 问题 1：纤程需要手动管理栈，容易出错
- 原因：
纤程切换需要手动保存/恢复栈指针、寄存器，容易出现：
栈溢出
栈损坏
未对齐导致崩溃 - 解决：
使用成熟的纤程库（Boost Fiber、Windows Fiber）
避免手写纤程切换逻辑
使用更高级的协程抽象
8.3.2 问题 2：纤程无法利用多核（默认单线程）
- 原因：
纤程调度通常在单线程执行，除非手动绑定多个 OS 线程。 - 解决：
使用 M:N 调度模型（如 Go）
或使用协程框架而不是裸纤程
8.3.3 问题 3：纤程阻塞会阻塞整个线程
- 原因：
纤程是用户态调度，如果执行阻塞 I/O，会阻塞整个 OS 线程。 - 解决：
使用非阻塞 I/O
使用 I/O 线程池
使用更高级的协程框架（如 Go runtime）
8.4 虚拟线程
8.4.1 问题 1：虚拟线程数量过多导致调度压力
- 原因：
虽然虚拟线程轻量，但创建百万级虚拟线程仍会给 JVM 带来调度压力。 - 解决：
控制虚拟线程数量
使用虚拟线程池（Executor.newVirtualThreadPerTaskExecutor）
避免无限创建
8.4.2 问题 2：阻塞操作仍然可能导致性能下降
- 原因：
虚拟线程可以挂起，但底层 OS 线程仍可能被某些 native 调用阻塞。 - 解决：
避免使用阻塞的 JNI 调用
使用 Loom 兼容的非阻塞 I/O
避免 synchronized 长时间锁持有
8.4.3 问题 3：虚拟线程泄漏
-
原因：
虚拟线程创建后未结束
无限等待
锁竞争导致线程挂起但不退出
-
解决：
使用 try-with-resources 管理虚拟线程
使用结构化并发（StructuredTaskScope）
监控虚拟线程数量
8.4.4 问题 4：虚拟线程与传统线程池混用导致问题
-
原因：
虚拟线程不需要池，但开发者习惯性使用线程池，导致：
虚拟线程被限制
失去高并发优势
-
解决：
不要为虚拟线程使用固定大小线程池
使用 per-task executor
8.5 对比
| 模型 | 常见问题 | 根本原因 | 解决方案 |
|---|---|---|---|
| 线程 | 数量受限、泄漏、切换慢 | 栈大、内核态调度 | 线程池、减少阻塞 |
| 协程 | 泄漏、阻塞调度器、不公平 | 协作式调度、用户态 | 非阻塞 I/O、结构化并发 |
| 纤程 | 栈管理复杂、阻塞问题 | 手动栈切换、用户态 | 使用库、避免阻塞 |
| 虚拟线程 | 调度压力、阻塞 JNI、泄漏 | JVM 调度、分段栈 | 结构化并发、避免阻塞调用 |