Project Loom 的 Carrier Thread 映射机制是理解虚拟线程（Virtual Thread）在底层操作系统线程上调度逻辑的关键。以下是对这一机制的深入解析，帮助你更好地理解虚拟线程的调度行为。一、什么是 Carrier Thread？在 Project Loom 中，Carrier Thread 是一个由 JVM 管理的“载体线程”，它负责承载多个虚拟线程的执行。这些虚拟线程

Project Loom 的 Carrier Thread 是 JVM 实现高并发虚拟线程调度的核心机制——它并非特殊线程，而是可被动态复用的普通平台线程（如 ForkJoinPool 工作线程），仅临时承载虚拟线程执行上下文（Continuation），在 I/O 阻塞、sleep 或 park 等挂起点自动卸载当前虚拟线程并切换至其他就绪任务，从而以极低开销实现百万级虚拟线程的高效调度；理解其“多对一、非绑定、OS 可调度但不阻塞全局”的本质，能帮你彻底摆脱手动管理线程载体的误区，聚焦于编写真正可伸缩、可中断的异步代码。

Project Loom 的虚拟线程（Virtual Thread）并不固定绑定 OS 线程，Carrier Thread 只是临时“承载”它执行的普通平台线程——理解这点，就避开了绝大多数调度误解。

Carrier Thread 是什么，和普通 Thread 有什么区别

Carrier Thread 本质就是 ForkJoinPool.commonPool() 中的 worker thread 或显式创建的 Thread，它没有特殊标记、不继承新类、也不绕过 JVM 线程模型。唯一特殊之处在于：JVM 在其栈上动态挂载/卸载虚拟线程的执行上下文（即 Continuation），而非靠 OS 调度切换。

• 它可能被多个虚拟线程复用，也可能在一次 park/unpark 后换到另一个 Carrier 上
• 它自己仍受 OS 调度器管理（如 Linux 的 CFS），但它的阻塞（如 I/O、sleep）不会拖垮整个虚拟线程池
• 你无法通过 Thread.currentThread() 拿到当前运行的虚拟线程——得用 Thread.ofVirtual().name() 或 JFR 事件观察

虚拟线程何时会切换 Carrier Thread

切换不是由时间片或优先级驱动，而是由“阻塞点 + 调度策略”触发。典型场景包括：

• 调用 BlockingChannel.read(...)、ServerSocket.accept() 等阻塞 I/O 时，JVM 自动将当前虚拟线程从 Carrier 上卸载，并唤醒另一个就绪的虚拟线程继续使用该 Carrier
• 显式调用 Thread.sleep() 或 LockSupport.park()，也会触发卸载；但 Object.wait() 不会（需配合 synchronized 块内使用，且 Loom 已重写其语义）
• 如果所有 Carrier 都忙于计算（无空闲），新虚拟线程会排队等待；若配置了 -Djdk.virtualThreadScheduler.parallelism=N，最多启用 N 个 Carrier 并发执行

怎么观测虚拟线程与 Carrier 的映射关系

不能靠日志打 Thread.currentThread().getName()——那永远只显示 Carrier 名（如 ForkJoinPool-1-worker-3）。真实映射必须依赖 JVM 内置机制：

• 开启 JFR 事件：jcmd VM.native_memory summary + jcmd VM.start_flightrecording settings=profile,duration=30s，然后用 JDK Mission Control 查看 jdk.VirtualThreadSubmitFailed、jdk.VirtualThreadPinned 等事件
• 用 jdk.jfr.consumer.RecordingStream 编程读取，过滤 jdk.VirtualThreadMount 和 jdk.VirtualThreadUnmount，其中 carrierId 字段对应 OS 线程 ID（tid），virtualThreadId 是 JVM 内部编号
• 避免误判：Thread.activeCount() 统计的是 Carrier 数量，不是虚拟线程数；查虚拟线程总数得用 Thread.getAllStackTraces().keySet().stream().filter(Thread::isVirtual).count()

常见误用：把 Carrier 当作“线程池”来手动管理

有人试图用 Thread.Builder.ofPlatform().name("my-carrier").start() 创建专属 Carrier 并长期绑定虚拟线程，这是反模式：

• Carrier 不具备亲和性（affinity）保证，JVM 可能在任意时刻将其用于其他虚拟线程
• 手动控制 Carrier 会破坏 Loom 的自适应调度（比如阻塞后无法自动迁移，导致 Carrier “卡死”）
• 唯一可控的入口是 Thread.ofVirtual().scheduler(ExecutorService)，但传入的 ExecutorService 仅决定虚拟线程的“启动位置”，不影响后续调度——真正调度权始终在 JVM 的 ForkJoinPool 调度器手上

真正需要干预的点，其实是让阻塞操作可中断（如用 AsynchronousFileChannel 替代 FileInputStream），而不是操心哪个 Carrier 在跑哪条虚拟线程。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~