ProjectLoom虚拟线程映射机制解析

Project Loom 的 Carrier Thread 机制彻底颠覆了传统线程模型——它让成千上万的虚拟线程轻量、高效地复用少量操作系统线程，而非一对一绑定；当虚拟线程执行时临时“挂载”到载体线程上，一旦遇到 sleep、I/O 或显式阻塞便瞬间“卸载”，立即将载体线程腾出给其他就绪虚拟线程，整个过程对开发者完全透明且零感知；这种动态、协作式的调度不仅极大降低了内存与内核开销，更将并发编程从线程资源焦虑中解放出来——但前提是避免在虚拟线程中做长时间 CPU 运算、滥用原生锁或不可中断的阻塞操作，否则反而会拖垮整个复用池。

Carrier Thread 是什么，它和虚拟线程不是一对一关系

Carrier Thread（载体线程）是真实运行在操作系统上的平台线程，JVM 用它来“承载”多个虚拟线程的执行。虚拟线程本身不绑定 OS 线程，只有当它需要执行代码时，才被临时挂载（mount）到某个 carrier thread 上；一旦阻塞（比如 Thread.sleep()、Socket.read()、数据库查询），JVM 就会立刻卸载（unmount）它，并把 carrier thread 让给其他就绪的虚拟线程——这个过程对用户代码完全透明。

常见误解是“每个虚拟线程对应一个 carrier thread”，其实相反：默认情况下，JVM 只维护一个固定大小的 carrier thread 池（通常是 CPU 核心数 × 2），所有虚拟线程都复用这组线程。你可以用 jcmd VM.native_memory summary 观察实际 OS 线程数远低于虚拟线程数。

如何验证虚拟线程正在复用 carrier thread

最直接的方式是打印线程名并观察日志规律：

Thread.ofVirtual().name("vt-").start(() -> {
    System.out.println("VT: " + Thread.currentThread().getName() +
                       ", carrier: " + Thread.currentThread().getThreadGroup().getName());
});

你会看到类似输出：

VT: vt-1, carrier: carrier-1
VT: vt-2, carrier: carrier-1
VT: vt-3, carrier: carrier-2

说明多个虚拟线程共享了同一个 carrier thread。注意：Thread.currentThread().getThreadGroup().getName() 在 JDK 21+ 中返回 carrier thread 所属线程组名（如 carrier-1），这是识别映射关系的关键线索。

如果你用 Executors.newVirtualThreadPerTaskExecutor() 提交大量任务，再用 jstack 查看线程栈，会发现只有少量 ForkJoinPool 工作线程（即 carrier threads），而数百个虚拟线程状态为 WAITING 或 BLOCKED，但都挂在这些线程之下。

为什么 carrier thread 数量不能随便调大

carrier thread 是真正的 OS 线程，每增加一个就多消耗约 1MB 栈空间 + 内核调度开销。盲目扩大 carrier thread 数量反而会导致：

• 上下文切换频率上升，抵消虚拟线程带来的低开销优势
• 内存占用陡增，尤其在容器环境中容易触发 OOM
• JVM 默认不暴露 carrier thread 数量配置接口，强行通过反射修改内部字段（如 ForkJoinPool.commonPool() 的 parallelism）属于未定义行为，不同 JDK 版本表现不一致

真正可控的是虚拟线程的行为：让它们尽快完成或进入阻塞态，从而释放 carrier thread。例如，避免在虚拟线程中做长时间 CPU 密集运算（应交给 Executors.newFixedThreadPool()）；I/O 操作尽量用标准阻塞 API（InputStream.read()），JVM 才能自动识别并卸载。

Carrier thread 被长期占用的典型场景和对策

当 carrier thread 被某个虚拟线程独占太久，其他虚拟线程就会排队等待，整体吞吐下降。典型诱因包括：

• 在虚拟线程中调用 Thread.sleep(Long.MAX_VALUE) 或死循环（无阻塞点）
• 使用 native 方法或 JNI 调用且未声明为可中断（JVM 无法安全卸载）
• 第三方库内部用了 synchronized 块 + 长时间持有锁，导致虚拟线程无法及时让出 carrier thread

对策很明确：用 jfr 录制运行时事件，重点关注 jdk.VirtualThreadMount 和 jdk.VirtualThreadUnmount 事件的时间差。如果 unmount 延迟超过 10ms，就要检查对应虚拟线程是否做了不该做的事。

真正难察觉的是“伪阻塞”：比如用 ReentrantLock.lock() 等待，JVM 不知道这是可协作让出的点，仍会把 carrier thread 占着。这时候必须换用 LockSupport.park() 或显式 Thread.yield() 插桩，或者干脆避开锁竞争路径。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ProjectLoom虚拟线程映射机制解析》文章吧，也可关注golang学习网公众号了解相关技术文章。