虚拟线程与Project Loom

可视化演示

展示虚拟线程M:N调度模型（多虚拟线程映射少载体线程挂载卸载）、虚拟线程vs平台线程对比（内存1:500/并发1000x/创建成本）与Continuation挂起恢复机制（栈帧捕获yield→Heap→remount），交互切换核心技术。

1. Loom项目背景：Java的并发之痛

老式餐厅最怕什么？怕客人多，更怕客人坐下来只看不点。每一位顾客都必须配一位全程陪同的服务员（平台线程），哪怕顾客只是发呆半小时，服务员也得陪着。Java 多年来的并发模型就是这样：一个请求占一个线程，线程是操作系统提供的“专职服务员”，创建要花时间、占内存（默认栈约 1MB），而且一旦阻塞在 I/O 上就彻底空闲。为了控制成本，大家只好用线程池固定服务员数量——客人一多，剩下的人只能在门口排队。

虚拟线程并非凭空发明，其他语言早有类似方案：Go 的 Goroutine、Ruby 的 Fiber（纤程），本质都是“用户态调度的轻量级任务”。Project Loom 是 Java 官方给出的答案：让 JVM 自己管理海量轻量线程，把“服务员”和“顾客”解耦，把操作系统线程从“一对一陪伴”中解放出来。

传统线程能开多少，直接受内存约束：

Loom 的愿景，就是给 Java 开一家“叫号快餐厅”：不再为每位顾客配专属服务员，而是让顾客拿着号单（虚拟线程）自由活动，让收银员（平台线程）高效轮转起来。

2. 虚拟线程原理：一张叫号单

新式快餐厅里，顾客进门领一张叫号单。叫号单很便宜，一叠纸只要几块钱，发出去一万张也不心疼；但收银员很贵，店里只雇两三位。虚拟线程正是这张“叫号单”——它记录了顾客（任务）的身份、状态和要执行的事，但本身不占用“人力”。

虚拟线程是 java.lang.Thread 的实例，却由 JVM 在用户态创建和调度，不再一对一绑定操作系统线程。真正干活的是“载体线程”（Carrier Thread），也就是平台线程。当一个虚拟线程需要运行 CPU 指令时，JVM 把它挂到某个空闲的载体线程上；当它阻塞时，就把它从载体线程上摘下来。这就是经典的 M:N 映射模型：

每张叫号单只是一份轻量记录，虚拟线程的栈初始只有几 KB，按需增长。于是你可以大方地“每个任务发一张单子”，再也不用精打细算地复用线程。

3. 调度机制：叫号系统的运转

叫号快餐厅里有个隐形的大脑——叫号系统（调度器）。它盯着所有叫号单：谁的餐好了，就叫谁来取；谁还在等，就让他继续等。虚拟线程的调度器是 JVM 内置的，它会在虚拟线程执行阻塞操作时自动介入。

当虚拟线程执行 Thread.sleep()、Socket 读写、等待锁这类阻塞操作时，JVM 会把它挂起，立刻从载体线程上摘下来；载体线程转头就去执行另一个就绪的虚拟线程。等阻塞结束后，虚拟线程重新进入就绪队列，等待调度器再次把它放上载体线程。这个切换完全在用户态完成，不经过操作系统内核：

需要警惕的是“钉住”现象：如果虚拟线程在 synchronized 同步块内阻塞，JVM 无法在锁边界安全挂起，载体线程会被“钉住”空等。这就像收银员被一个顾客拽住袖子不放，没法去服务别人——调度机制虽好，用错锁依然会卡住。

4. 性能优势：同样的店，十倍接待量

同样是几十平米的店面，老餐厅极限接待 20 桌客人，新餐厅却敢发 2000 张号单。因为前者每个顾客占一个服务员，后者所有顾客共享两三个收银员。虚拟线程的性能优势，来自三个层面的“瘦身”。

首先是内存。平台线程栈默认约 1MB，虚拟线程初始栈只有几 KB；其次是创建成本，平台线程创建需要系统调用，耗时毫秒级，虚拟线程纯粹在堆上分配，耗时微秒级；最后是切换成本，前面说过差了两个数量级。三者叠加，让 Java 应用第一次能轻松创建几十万甚至上百万个并发任务。

简单说，过去线程池卡在几百上千并发，虚拟线程能直接拉到十万级。吞吐量提升不是靠“跑得更快”，而是靠“不再傻等”。

5. 结构化并发：包厢里的整桌管理

新餐厅还有一种高阶服务：包厢。一桌客人点了八道菜，后厨必须等这桌的菜全部上齐才算服务完成；如果客人中途要退单，后厨也得把没上的菜全部取消，不能让菜炒到一半滞留。结构化并发（StructuredTaskScope）就是这种“包厢管理”。

在传统异步编程里，你 submit 一堆任务到线程池，很难统一管理它们的生命周期——要么忘记等待，要么任务抛异常后其他任务还在后台继续跑。结构化并发要求：子任务的生命周期必须限定在代码块之内。你 fork 出去的每个子任务，都在同一个 StructuredTaskScope 中运行，join 会等待全部子任务结束；一旦任一子任务失败，其余未完成的子任务会被自动取消，异常统一抛出。

结构化并发把“发散-汇合”的并发模式变得像写同步代码一样清晰。包厢里要么整桌好菜上齐，要么整桌取消，绝不让菜滞留后厨——这正好解决了虚拟线程时代“任务太多管不过来”的新问题。

6. 应用场景：新模式的用武之地

叫号模式适合所有“顾客多、等待久”的餐厅：火锅店等位长、快餐店翻台快、外卖店单量爆炸。对应到 Java 世界，凡是阻塞占比高、并发量大、每个请求都要等外部资源的场景，都是虚拟线程的主场。

高并发 Web 服务是最典型的场景。传统 Tomcat 线程池默认 200，每个请求占一个平台线程，遇到数据库慢查询就集体卡死。换成虚拟线程后，每个请求一个虚拟线程，容器只需要少量载体线程即可承接海量并发。阻塞 JDBC 访问同样受益：JDBC 驱动是阻塞 API，过去只能靠加大线程池硬扛，现在虚拟线程让阻塞调用不再浪费平台线程。API 网关/代理转发到下游服务时，长时间等待响应也不会耗尽线程。

收益可以用一个简单的公式估算：

反过来，纯 CPU 密集型计算（图像渲染、矩阵运算）中几乎不阻塞，虚拟线程优势很小——就像高档法餐厅，顾客本来就安静用餐，叫号单反而多余。

7. 最佳实践：经营新餐厅的守则

叫号模式虽好，经营也有门道。第一条守则是不要池化虚拟线程。平台线程稀缺才需要池化，虚拟线程廉价到可以“每任务创建”，池化反而引入排队和复杂度。第二条是用信号量（Semaphore）限制对下游资源的并发访问。虚拟线程再多，数据库连接池只有 100 个，你得控制同时访问数据库的虚拟线程数，而不是让它们一窝蜂冲上去。

第三条是避免在虚拟线程中使用 synchronized。前面说过钉住现象，推荐改用 ReentrantLock，让 JVM 能在锁等待时安全挂起虚拟线程。第四条是用 ScopedValue 替代 ThreadLocal——虚拟线程可能数以万计，ThreadLocal 变量会随之膨胀内存，作用域值更安全可控。迁移策略上，优先改造 IO 密集的服务模块，先小范围验证再全面铺开。

锁竞争程度决定了钉住风险的大小：

遵循这些守则，你的“新餐厅”才能在高峰时段游刃有余：叫号单随手发、收银员不空转、后厨不积压。虚拟线程不是银弹，用对地方它就是高并发系统最锋利的刀。

AI 应用场景

Python 演示

import asyncioimport threadingimport time  def spawn_threads(n: int) -> float:    """模拟传统平台线程：创建 n 个 OS 线程并行执行"""    start = time.perf_counter()    threads = []    for _ in range(n):        t = threading.Thread(target=lambda: time.sleep(0.02))        threads.append(t)        t.start()    for t in threads:        t.join()    return time.perf_counter() - start  def spawn_tasks(n: int) -> float:    """模拟虚拟线程模型：创建 n 个轻量任务由事件循环调度"""    start = time.perf_counter()     async def main():        await asyncio.gather(*(asyncio.sleep(0.02) for _ in range(n)))     asyncio.run(main())    return time.perf_counter() - start  if __name__ == "__main__":    n = 100    t_platform = spawn_threads(n)    t_lightweight = spawn_tasks(n)    print(f"platform threads: {t_platform:.3f}s")    print(f"lightweight tasks: {t_lightweight:.3f}s")    print(f"speedup: {t_platform / t_lightweight:.1f}x")

1. threading.Thread(target=lambda: time.sleep(0.02))为每个任务创建一个操作系统线程，对应“每个顾客配一个服务员”
2. threads.append(t); t.start()启动线程并加入列表，线程启动后立即并发运行
3. t.join()主线程等待所有平台线程结束，类似传统 ExecutorService 的 shutdown()+awaitTermination()
4. async def main()定义一个协程入口，对应虚拟线程模型中“一个任务一个协程”
5. asyncio.gather(*(asyncio.sleep(0.02) for _ in range(n)))一次性创建 n 个轻量任务并发执行，对应虚拟线程的“每任务一个虚拟线程”
6. asyncio.run(main())事件循环在单线程内调度所有协程，对应 JVM 调度器在载体线程上切换虚拟线程
7. time.perf_counter()高精度计时，对比两种模型的创建与切换总开销

常见误区

面试题