虚拟线程：等的时候把线程让出来，但在 synchronized 里让不出来

• 平台线程一对一占一个操作系统线程：要预留一段栈，创建一个要几十微秒（线程页实测 82～94 µs），切换一次几微秒。几千个就开始吃不消，所以只能放进池子、限着数量用。
• 池子满了，等的线程也占着名额：实测 1 万个“等下游 100 ms”的任务，200 线程的池子要 5037 ms，CPU 几乎全程闲着（⑤）。
• 老办法一：加线程，内存和切换跟着涨；老办法二：改成异步（CompletableFuture、Reactor），线程不再傻等，但代码被拆成一节一节的回调，异常栈、调试、ThreadLocal 全变难（上一页）。
• 缺的那一块：线程便宜到“一个请求一个”，阻塞时自动把底下的操作系统线程让出来。这就是虚拟线程（JDK 21 正式，JEP 444）。

不懂这一点时的典型误用：以为“线程多了、快了”，什么都能解决。实测 全景第 2 站换成虚拟线程后，一次压测开出了 941 个线程，没加锁的扣库存照样超卖（109 件）：虚拟线程不改变并发正确性，竞态、锁、可见性的规矩一条都没少。

选择规则：并发高、大部分时间在等 IO 的服务（典型的 Spring MVC 业务），JDK 21 以上用虚拟线程；计算密集的活继续用按核数配的平台线程池；已经是响应式的链路不用改。本页学虚拟线程的机制、钉住，以及什么时候不该用。

④-1机制：虚拟线程 = 一段可以暂停的栈 + 一个调度器

• 1阻塞点都被 JDK 改造过：socket、Thread.sleep、LockSupport.park（所以 AQS 系的锁、阻塞队列、CompletableFuture.get 都行）在虚拟线程里会卸载，而不是让操作系统线程睡着。
• 2有些阻塞卸不下来，但会补偿：很多文件 IO 和 Object.wait() 会占住载体线程，JDK 21 用临时多开一个载体线程来补偿（按 JEP 444）。synchronized 里的 sleep / IO 不补偿，这就是 ⑤ 里 5030 ms 的由来。
• 3没有时间片：调度器不会把一个一直在算的虚拟线程强行换下来（按 JEP 444），它只在阻塞时让出。所以长计算会霸占载体线程。

④-2动手看载体线程：卸载和钉住

就绪队列按先进先出排，真实的 ForkJoinPool 有工作窃取，顺序不同，但总耗时的量级一样。在 node 里用“100 个虚拟线程、2 个载体、只等 100 ms”跑了一遍：卸载 101 ms、钉住 5001 ms，⑤ 实测是 125 ms 和 5030 ms。

④-3钉住：怎么发现，怎么修

• 1修法一：把 synchronized 换成 ReentrantLock。它排队和等待走 LockSupport.park，能卸载。实测 5030 ms → 125 ms。只需要改“锁里面会阻塞”的那些，锁里只做内存操作的 synchronized 不用动。
• 2修法二：把阻塞挪到锁外：先查好、算好，锁里只改内存。
• 3修法三：升级 JDK。JDK 24 的 JEP 491 让 synchronized 不再钉住（它同时去掉了 jdk.tracePinnedThreads）；native 帧仍会钉住。第三方库（老版本 JDBC 驱动、连接池）里的 synchronized 你改不了，这条最省事。

④-4什么时候用，什么时候别用

④-5和 J02 前八个知识点对照

④-6为什么这样设计：不给函数分颜色

决定胜负的约束：Java 已经有海量的同步代码和库。让它们原封不动地享受“等的时候不占线程”，比让所有人重写成异步划算。代价是 JDK 自己要把阻塞点都改造好，JDK 21 时还没改完 synchronized，到 JDK 24 才补上。

Thread.ofVirtual().name("order-", 0).start(() -> placeOrder());   // 起一个

try (ExecutorService es = Executors.newVirtualThreadPerTaskExecutor()) {   // 每个任务一个，不是池
  for (Order o : orders) es.submit(() -> notify(o));
}                                                                   // close() 等全部做完

Semaphore smsLimit = new Semaphore(20);                               // 限并发靠它，不靠线程数
smsLimit.acquire(); try { sms.send(o); } finally { smsLimit.release(); }

# Spring Boot 3.2+：Tomcat 请求、@Async 等都换成虚拟线程
spring.threads.virtual.enabled=true

Spring 打开开关后具体换了哪些执行器、JDK 24/25 的变化、怎么在线程转储里看虚拟线程，放到第⑥步。

实验 1：1 万个“等下游 100 ms”的任务，和 200 个计算任务

$ java -cp … Throughput io
CPU 核数 2，任务 10000 个，类型 io
  平台线程池 200        5037 ms，真正干活的操作系统线程 200 个
  虚拟线程 每任务一个    265 ms，真正干活的操作系统线程 2 个
（第二次：5034 ms / 242 ms）

$ java -cp … Throughput cpu [vt-first]    # 200 个任务，每个单独跑约 20 ms 的计算
平台先跑：平台 3733 ms，虚拟线程 2067 ms   （两次：3733/2067、3901/2221）
虚拟先跑：虚拟线程 3197 ms，平台 2129 ms   （两次：3197/2129、3373/2160）

• 1等 IO：200 线程的池子要 1 万 ÷ 200 = 50 批，每批 100 ms，正好 5 秒；虚拟线程 1 万个同时睡，只用 2 个载体线程，约 0.25 秒。
• 2算：谁先跑谁慢（JIT 还没热身），后跑的那一组平台线程和虚拟线程都在 2.1～2.2 秒，正好是“4 秒计算量 ÷ 2 核”。虚拟线程不会多变出 CPU。

实验 2：100 个虚拟线程，各自拿一把锁，在锁里等 100 ms（2 个载体线程）

$ java -Djdk.virtualThreadScheduler.parallelism=2 -cp … Pinning sync
模式 sync ：100 个虚拟线程、各等 100 ms，用了 5030 ms（载体线程 2 个）
$ java … Pinning lock
模式 lock ：100 个虚拟线程、各等 100 ms，用了 125 ms（载体线程 2 个）

$ java -Djdk.tracePinnedThreads=short … Pinning sync
VirtualThread[#20]/runnable@ForkJoinPool-1-worker-2 reason:MONITOR
    labs.juc.virtual_threads_pinning.Pinning.lambda$main$0(Pinning.java:23) <== monitors:1

$ java -XX:StartFlightRecording=filename=pin.jfr … Pinning sync && jfr summary pin.jfr
 jdk.VirtualThreadPinned                   100          1400
$ jfr print --events jdk.VirtualThreadPinned --stack-depth 3 pin.jfr
jdk.VirtualThreadPinned { duration = 98.9 ms … java.lang.VirtualThread.parkOnCarrierThread … }

• 1每把锁只有一个线程用，没有任何锁竞争，慢全来自钉住：100 个 × 100 ms ÷ 2 个载体 = 5 秒。换成 ReentrantLock 后 100 个同时睡，约 0.1 秒。
• 2两个工具都直接指到了代码行：trace 指出 Pinning.java:23 持有 1 个监视器；JFR 里 100 条事件、每条约 100 ms，栈顶是 parkOnCarrierThread（在载体线程上停着，而不是卸载）。

• Continuation 源码：yield 时栈帧怎么拷进 StackChunk、挂载时怎么懒拷回来
• StructuredTaskScope + ScopedValue：把全景第 10 站的三条通知改写成结构化并发，一个失败其余真正取消
• 在 JDK 24/25 上重跑 ⑤ 实验 2，看 synchronized 版是不是也变成 100 ms 左右（JEP 491）
• HikariCP、MySQL 驱动在虚拟线程下的表现：哪些版本还有 synchronized 钉住
• 交易靶场整体切到虚拟线程后压一遍：瓶颈挪到了哪里（J12 限流、J13 监控）

自测