Java虚拟线程深度架构：从Fiber模型到百万并发调度的工程实践

一、并发模型演进：从线程池到虚拟线程的认知跃迁

1.1 三个时代的并发模型

Java并发编程经历了三次根本性的认知跃迁，每一次跃迁都解决了上一代的核心痛点，但同时也引入了新的复杂度。理解这三个时代的演进逻辑，是掌握虚拟线程架构设计哲学的前提。

Thread 1.0时代（1996-2004）：每个Thread对象与OS线程1:1绑定。优势是编程模型最简单——new Thread(r).start()即可，JVM对线程调度几乎不参与。劣势同样明显：每个线程占用1MB栈空间（默认），4GB堆内存最多支撑约4000线程，线程数突破1万后JVM直接OOM。这是典型的"零成本抽象"反面——上层API的简洁换不来下层资源的廉价。

ThreadPool 1.5时代（2004-2023）：JDK5引入Executor框架，线程池通过复用OS线程缓解了创建开销。ThreadPoolExecutor成为Java后端服务的事实标准，配合有界队列和拒绝策略，构成了高并发服务的骨架。但线程池没有解决根本问题——池大小受限于OS线程数，CPU密集与I/O密集任务在同一个池中争抢资源，池满后请求被拒绝而非排队阻塞。

VirtualThread 21时代（2023-）：Project Loom历经7年研发，JDK21正式发布虚拟线程。核心范式转换是M:N调度——M个虚拟线程（百万级）映射到N个OS线程（CPU核心数）。虚拟线程创建成本约300字节（初始栈+Continuation对象），相比Thread的1MB降低3000倍。阻塞I/O自动让出底层OS线程，不再消耗Carrier资源。

并发模型演进架构

Thread 1.0            ThreadPool 1.5            VirtualThread 21
┌──────────┐          ┌──────────┐              ┌──────────────────┐
│ App      │          │ App      │              │ App              │
│ 1000线程  │          │ 200线程池 │              │ 1,000,000虚拟线程 │
└────┬─────┘          └────┬─────┘              └────────┬─────────┘
     │1:1                  │1:1                         │M:N
┌────▼─────┐          ┌────▼─────┐              ┌─────────▼────────┐
│ OS       │          │ OS       │              │ ForkJoinPool     │
│ 1000线程  │          │ 200线程   │              │ CPU核心数Carrier │
└──────────┘          └──────────┘              └──────────────────┘

瓶颈：OS线程数          瓶颈：池拒绝策略             瓶颈：CPU算力本身
      

1.2 认知误区：虚拟线程不是线程池的替代

大量团队把虚拟线程当作"无限大的线程池"使用——newVirtualThreadPerTaskExecutor替代newFixedThreadPool，池大小参数照搬，业务代码一行不改就上线。这是极其危险的认知误区。虚拟线程的设计哲学与线程池完全相反：池化的核心是"复用稀缺资源"，而虚拟线程本身不是稀缺资源，复用没有意义。池化虚拟线程会导致：

第一，失去M:N调度的核心优势。如果把虚拟线程池化限制为200大小，等同于把百万级并发能力压缩回200线程上限。第二，背压机制缺失。线程池的有界队列+拒绝策略是天然背压，池化虚拟线程后变成无界任务堆积，JVM直接OOM。第三，失去栈深度弹性的优势。虚拟线程按需伸缩栈深度，池化会让所有虚拟线程共享预分配栈结构。

1.3 历史定位：为什么Loom花了7年

Project Loom从2017年立项到2023年GA，经历了6个Preview版本和3个孵化器阶段。研发周期长不是因为实现复杂，而是因为虚拟线程触及了JVM最深层的栈管理机制——栈帧的保存与恢复、栈内存的延迟分配、native方法的栈边界处理，每一项都是字节码解释器与JIT编译器的深度耦合点。Loom团队选择不破坏现有Java语义、不引入新的关键字、不改变任何类库的API签名，这种"零侵入"的设计哲学让项目周期被显著拉长，但换来的是生态的完全兼容——任何JDK8时代的代码，在JDK21虚拟线程下都能获得并发能力提升，无需重写。

二、虚拟线程调度架构：ForkJoinPool与Continuation的协作闭环

2.1 ForkJoinPool的work-stealing核心机制

虚拟线程调度器底层是ForkJoinPool，每个Carrier线程对应ForkJoinPool的一个worker。ForkJoinPool的核心是work-stealing算法：每个worker维护一个双端任务队列（deque），新任务从队头入队（push），worker自己从队头取任务执行（poll），当自身队列为空时从其他worker的队尾窃取任务（steal）。这种"自己LIFO、别人FIFO"的设计减少了线程间的任务竞争，最大化缓存局部性。

对于虚拟线程场景，ForkJoinPool的角色从"执行器"升级为"调度基础设施"。当虚拟线程被提交时，它被包装为一个ForkJoinTask，提交到当前Carrier所在worker的deque头。当虚拟线程执行阻塞I/O时，Continuation.save()保存栈帧到堆内存，worker的deque头部的任务被标记为"挂起"，worker从deque尾部取下一个可运行虚拟线程执行。整个过程对应用代码完全透明。

ForkJoinPool work-stealing + 虚拟线程调度架构

Carrier 1 deque          Carrier 2 deque          Carrier 3 deque
┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ VT-A (运行) │ 头      │ VT-D (运行) │ 头      │ VT-G (运行) │ 头
│ VT-B (就绪) │         │ VT-E (挂起) │         │ VT-H (就绪) │
│ VT-C (就绪) │ 尾      │ VT-F (就绪) │ 尾      │ VT-I (挂起) │ 尾
└─────────────┘         └─────────────┘         └─────────────┘
       │                      │                       │
       └──────────────────────┴───────────────────────┘
                              │
                    队列空时跨Carrier窃取
                    减少锁竞争 + 提升缓存局部性
      

2.2 Continuation的挂起恢复原语

Continuation是JVM内部用于管理虚拟线程栈帧的对象，API为jdk.internal.vm.Continuation（外部应用不可直接调用）。每次虚拟线程阻塞时，JVM调用Continuation.yield()将栈帧从Carrier线程的栈空间复制到堆上，释放Carrier；I/O就绪时，JVM调用Continuation.run()从堆上恢复栈帧到Carrier线程的栈空间，继续执行。

这个"栈帧序列化到堆"的设计带来三个关键收益：第一，栈深度弹性——虚拟线程初始栈仅几KB，遇到深递归调用时按需扩展（最大到OS线程栈大小），避免1MB预分配浪费。第二，状态可持久化——栈帧是普通对象，可以被GC、可被序列化到磁盘、可被复制到其他节点。第三，调试友好——jstack能直接dump虚拟线程的完整调用栈，不像Kotlin协程的浅栈需要手动追踪状态机。

2.3 与Kotlin协程的架构差异

Kotlin协程是编译期变换，编译器将suspend函数拆分为多个状态机阶段，运行在共享线程池上。协程的"挂起"本质上是状态机的状态转移，调用栈被拆散保存到Continuation对象的字段中。虚拟线程的"挂起"是JVM级操作，完整的调用栈以原生栈帧数组形式保存。

三、Carrier Thread池化策略：大小选择与饱和治理

3.1 默认大小的设计推导

Carrier线程数默认等于CPU核心数，这是经过严格推导的最优值。推导逻辑是：Carrier线程只占用CPU时间片执行虚拟线程的CPU计算部分，当虚拟线程阻塞在I/O时Carrier自动释放给其他虚拟线程。因此Carrier数量等于CPU核心数时，所有CPU核都被充分利用且无上下文切换开销——增加Carrier数不会提升吞吐，反而增加L1缓存失效和TLB miss。

JVM参数可调：-Djdk.virtualThreadScheduler.parallelism=8（核心数）、-Djdk.virtualThreadScheduler.maxPoolSize=8（最大数，默认等于核心数）、-Djdk.virtualThreadScheduler.minRunnable=1（最小保持运行的Carrier数）。生产环境强烈建议保持默认——绝大多数场景CPU核心数就是最优解。

Carrier池容量架构

系统默认配置
├── 核心池大小 = CPU核心数（固定）
├── 最大池大小 = CPU核心数（可弹性扩展）
├── 空闲超时 = 30s
└── 工作队列 = 无界（虚拟线程按需提交）

自定义覆盖
├── jdk.virtualThreadScheduler.parallelism
├── jdk.virtualThreadScheduler.maxPoolSize
└── jdk.virtualThreadScheduler.minRunnable
      

3.2 饱和场景的三个表现

当所有Carrier线程被CPU密集型虚拟线程占满时，整个调度系统进入饱和状态。饱和有三个可观测表现：

第一，I/O型虚拟线程饥饿。CPU密集虚拟线程占满Carrier，I/O型虚拟线程提交后无法被调度执行，表现为请求延迟P99突然飙升到秒级。检测方法：JMX监控ForkJoinPool的queuedSubmissions指标，如果持续大于0且idle线程数为0，即为饱和。第二，Carrier的park率指标。如果park率长期低于5%（即Carrier几乎从不空闲），说明调度器长期满载。第三，虚拟线程堆积。通过JFR事件jdk.VirtualThreadSubmitFailed或JMX ThreadMXBean观察虚拟线程数量趋势——如果持续增长不收敛，说明提交速度超过调度速度。

3.3 治理策略：业务域隔离

饱和治理的核心思路是"按业务域隔离调度器"。不能让所有虚拟线程共享一个默认ForkJoinPool，否则一个业务的CPU密集任务会拖垮全局调度。架构模式如下：

业务域隔离架构

┌──────────────────────────────────────┐
│           应用层                      │
│  ┌────────┐ ┌────────┐ ┌────────┐  │
│  │交易域   │ │用户域   │ │报表域   │  │
│  │虚拟线程  │ │虚拟线程  │ │虚拟线程  │  │
│  └───┬────┘ └───┬────┘ └───┬────┘  │
│      │          │          │        │
│  ┌───▼────┐ ┌───▼────┐ ┌──▼────┐  │
│  │FJP交易  │ │FJP用户  │ │FJP报表│  │
│  │8 Carrier│ │4 Carrier│ │4 Carr│  │
│  └────────┘ └────────┘ └───────┘  │
└──────────────────────────────────────┘

隔离原则：
- CPU密集域与I/O密集域分池
- 高优先级业务（支付/交易）独立池
- 报表/批处理域限制Carrier数，避免抢主业务资源
      

四、Pin问题根因分析：synchronized与native方法的阻塞陷阱

4.1 Pin的本质：monitor锁阻止Continuation

Pin是虚拟线程最棘手的工程问题，本质是synchronized的monitor锁机制与Continuation的栈帧保存机制存在根本性冲突。JVM的设计是：线程持有monitor锁时，栈帧必须保留在OS线程上（因为monitor锁的owner信息记录在线程对象中）。当虚拟线程在synchronized块内执行阻塞操作时，JVM无法安全地保存栈帧——如果栈帧被序列化到堆上、Carrier释放给其他虚拟线程，但monitor锁的owner还是当前Carrier线程对应的虚拟线程对象，锁的语义就会被破坏。

为了避免这种破坏，JVM采取了保守策略：当虚拟线程在synchronized块内调用阻塞方法时，JVM会Pin住当前Carrier线程，阻止其被释放——这意味着Carrier线程被该虚拟线程独占，无法执行其他虚拟线程。这直接破坏了M:N调度的核心假设。

4.2 Pin的两种触发路径与检测

路径1：synchronized块内阻塞
synchronized(lock) {
    socket.read();  // ← Pin！Carrier无法释放
}

路径2：native方法内阻塞
ReentrantLock.lock();     // ✅ 可挂起
Object.wait();            // ✅ 可挂起（JDK21已优化）
Unsafe.park();            // ✅ 可挂起
FileChannel.read();       // ✅ 可挂起（NIO路径）
InputStream.read();       // ✅ 可挂起（JDK21默认）
native method();          // ❌ Pin
synchronized方法体;       // ❌ Pin
      

JDK提供了诊断开关：-Djdk.tracePinnedThreads=short/full。开启后Pin事件会打印线程栈和持有monitor的调用链。生产环境建议监控JFR事件jdk.VirtualThreadPinned，设置阈值告警。完整JFR事件列表还包括jdk.VirtualThreadSubmitFailed（调度失败）、jdk.VirtualThreadSleep（睡眠行为异常）。

4.3 Pin的连锁影响与放大效应

单个Pin事件的直接影响是Carrier线程被占用几毫秒到几秒，但连锁影响可能扩散到整个调度系统。如果一个热门业务锁（如库存锁）被Pin，持有锁的虚拟线程在执行慢I/O期间，所有其他需要该锁的虚拟线程都会阻塞，而Carrier线程也无法释放给I/O型虚拟线程——最终表现是P99延迟飙升，Carrier队列堆积，JVM进入类死锁状态。架构决策：虚拟线程路径上的所有synchronized块必须被识别和消除，这是上线前的硬性门控。

五、ReentrantLock替代方案：锁升级路径与性能度量

5.1 锁升级替换矩阵

消除Pin的标准做法是用ReentrantLock替换synchronized。ReentrantLock的阻塞路径经过了虚拟线程适配——lock()调用时如果获取失败，虚拟线程会通过LockSupport.park()挂起，JVM的LockSupport适配器会调用Continuation.yield()让出Carrier线程，整个过程不会触发Pin。

// 锁升级替换矩阵
synchronized(lock)         →  ReentrantLock lock = new ReentrantLock();
synchronized method        →  lock.lock()/unlock() 包裹方法体
Object.wait/notify         →  Condition.await/signal
ConcurrentHashMap.compute  →  无需替换（已适配虚拟线程）
StampedLock.readLock       →  无需替换（已适配虚拟线程）
Vector/Hashtable           →  替换为ArrayList/ConcurrentHashMap
StringBuffer               →  替换为StringBuilder
      

5.2 性能对比与决策依据

在非竞争场景下，synchronized经过JIT锁膨胀优化（偏向锁→轻量级锁→重量级锁）后性能优于ReentrantLock约15%——synchronized的加锁解锁是JVM内联指令，ReentrantLock要走Java方法调用栈。但虚拟线程下synchronized的Pin代价远超这15%的性能差异——一次热门锁Pin可能阻塞整个Carrier池数秒。

5.3 第三方库的Pin风险

业务代码替换ReentrantLock是可控的，但第三方库的内部synchronized块是黑盒。常见的Pin来源包括：JSON序列化库（Jackson/Gson的内部缓存锁）、日志框架（Log4j2的异步队列锁）、连接池（HikariCP的borrow等待锁）、ORM框架（Hibernate的一级缓存锁）。架构治理策略：选择已声明虚拟线程兼容的库（如Spring Boot 3.2+、Micrometer 1.13+），使用前查阅JEP 444兼容列表。

六、I/O阻塞与非阻塞：NIO集成与自动挂起机制

6.1 JDK21的核心适配工作

JDK21对java.net和java.io的核心类做了虚拟线程适配，这是Loom团队耗时最长的部分。Socket、ServerSocket、HttpClient等核心网络类在调用阻塞方法时，JVM会自动检测当前线程是否为虚拟线程，是则切换到NIO非阻塞模式。适配实现位于java.base/jdk.internal.net和java.base/java.net两个模块，共修改了200+类。

传统I/O适配架构

Socket.read()
    │
    ├─ JDK21 自动适配路径
    │   ├─ 检测当前是否为虚拟线程
    │   ├─ 是 → 切换到NIO非阻塞模式
    │   │       ├─ channel.configureBlocking(false)
    │   │       ├─ 注册到Selector
    │   │       └─ Continuation.save() 挂起
    │   └─ 否 → 保持传统阻塞I/O
    │
    └─ I/O完成 → Selector通知 → Continuation.resume()
      

6.2 第三方库的I/O适配现状

JDK核心类已适配，但第三方库未必。使用原生libuv、Netty的epoll直接调用、JNI网络库等，如果走的是native阻塞路径，仍然会Pin。决策原则：虚拟线程应用的全部I/O路径必须走JDK标准API，否则需要由独立的平台线程池承载。Netty 4.1.107+提供了EventLoopGroup + 虚拟线程的混合模式，但配置复杂，不建议生产使用。

6.3 JDBC驱动的Pin陷阱

JDBC是最容易被忽视的Pin来源。主流JDBC驱动（mysql-connector-j 8.x、postgresql 42.x、Oracle 21.x）内部使用synchronized保护连接状态，当数据库执行慢查询时，虚拟线程被Pin在synchronized块内，整个应用调度可能陷入类死锁状态。MySQL Connector/J 8.0.33+开始适配虚拟线程，PostgreSQL JDBC 42.7+同样适配。架构治理：升级到最新驱动 + 启用连接池（HikariCP）的虚拟线程兼容模式。

七、百万并发实战：线程池迁移与资源隔离架构

7.1 渐进式迁移路径

从线程池迁移到虚拟线程不是简单的new Thread替换，而是一次架构级的范式转换。核心思路是将"池化复用"的思维彻底换成"按需创建"的模式。推荐分四步走：

迁移四步走

Step 1: 识别（1-2周）
├── 梳理所有ExecutorService使用点
├── 分类：CPU密集 vs I/O密集
└── 标记每个池的大小配置来源（硬编码/配置中心）

Step 2: 试点（2-4周）
├── 选1-2个非核心业务试点
├── 替换为newVirtualThreadPerTaskExecutor
├── 开启Pin监控和JFR录制
└── 对比试点前后RT/P99/错误率

Step 3: 推广（4-8周）
├── 逐业务域替换执行器
├── 建立业务域隔离的ForkJoinPool
├── 完善Observability体系
└── 培训团队虚拟线程范式

Step 4: 收口（持续）
├── 移除所有线程池的池大小配置
├── 统一为虚拟线程工厂
├── 架构评审拦截新的线程池引入
└── 周期性审计Pin事件
      

7.2 迁移前后代码对比

// Before：池化思维
ExecutorService pool = Executors.newFixedThreadPool(200);
pool.submit(() -> handleRequest(req));
pool.shutdown();
pool.awaitTermination(30, TimeUnit.SECONDS);

// After：按需创建
ExecutorService vts = Executors.newVirtualThreadPerTaskExecutor();
vts.submit(() -> handleRequest(req));
// 无需shutdown/awaitTermination——虚拟线程用完即弃
      

7.3 资源隔离架构

生产环境不能让所有虚拟线程共享一个默认ForkJoinPool。需要按业务域隔离调度器，防止一个业务的CPU密集任务拖垮全局调度。

业务域隔离架构
┌──────────────────────────────────────┐
│           应用层                      │
│  ┌────────┐ ┌────────┐ ┌────────┐  │
│  │交易域   │ │用户域   │ │报表域   │  │
│  │虚拟线程  │ │虚拟线程  │ │虚拟线程  │  │
│  └───┬────┘ └───┬────┘ └───┬────┘  │
│      │          │          │        │
│  ┌───▼────┐ ┌───▼────┐ ┌──▼────┐  │
│  │FJP交易  │ │FJP用户  │ │FJP报表│  │
│  │8 Carrier│ │4 Carrier│ │4 Carr│  │
│  └────────┘ └────────┘ └───────┘  │
└──────────────────────────────────────┘
      

7.4 Spring Boot集成模式

Spring Boot 3.2+原生支持虚拟线程配置：spring.threads.virtual.enabled=true 即可全局启用所有Tomcat请求处理线程为虚拟线程。Spring MVC的@Async、@Scheduled、WebClient等组件同步适配。但需注意：阻塞的@Async方法仍会占用Carrier；@Scheduled默认使用单线程调度器，与虚拟线程无关。

八、可观测性：虚拟线程的监控与诊断体系

8.1 监控分层架构

虚拟线程带来新的可观测性挑战。jstack能看到虚拟线程栈，但百万线程的栈dump是灾难性的（dump过程会冻结所有线程数十秒）。需要精准采样而非全量dump。监控体系分四层：JFR事件层、JMX指标层、日志追踪层、业务指标层。

可观测性分层架构

┌─────────────────────────────────────────────┐
│ 业务指标层（Micrometer + Prometheus）       │
│ ├─ HTTP请求RT P50/P99/P999                 │
│ ├─ 业务错误率 / 业务成功率                 │
│ └─ 业务自定义计数器                        │
├─────────────────────────────────────────────┤
│ 运行时指标层（JMX）                         │
│ ├─ ForkJoinPool queue size / active count  │
│ ├─ ThreadMXBean 虚拟线程数量趋势           │
│ └─ Carrier线程CPU使用率                    │
├─────────────────────────────────────────────┤
│ 诊断事件层（JFR）                           │
│ ├─ jdk.VirtualThreadPinned                 │
│ ├─ jdk.VirtualThreadSubmitFailed           │
│ ├─ jdk.VirtualThreadSleep                  │
│ └─ jdk.CPULoad / jdk.GarbageCollection     │
├─────────────────────────────────────────────┤
│ 链路追踪层（OpenTelemetry）                 │
│ ├─ 每个虚拟线程的trace span                │
│ ├─ 跨线程的context propagation             │
│ └─ 慢请求的栈采样                          │
└─────────────────────────────────────────────┘
      

8.2 JFR录制配置模板

# JFR启动配置（生产环境推荐持续录制）
java -XX:StartFlightRecording:
     filename=app.jfr,
     duration=0s,
     maxsize=1G,
     maxage=1d,
     settings=profile

# 关键事件模板
jdk.VirtualThreadPinned#enabled=true
jdk.VirtualThreadPinned#threshold=10ms
jdk.VirtualThreadSubmitFailed#enabled=true
jdk.VirtualThreadSleep#enabled=true
jdk.CPULoad#enabled=true
      

8.3 关键指标与告警阈值

九、虚拟线程 vs Kotlin协程 vs Go goroutine：架构决策对比

9.1 三种并发模型的本质差异

三者的核心区别在于调度层的位置和透明度。Go将调度器嵌入运行时（G-P-M模型），Kotlin将状态机嵌入编译产物，Java将Continuation嵌入JVM。调度层越深，对应用层的侵入越低，但对运行时的改造越重。Go的G-M-P调度器是runtime的一部分，每个Go程序自带调度器；Kotlin协程是编译器产物，运行在JVM或Native上；Java虚拟线程是JVM 21+的内置特性，零代码侵入。

9.2 全维度对比表

9.3 Go G-M-P调度模型深度解析

Go的调度器由三个核心实体组成：G（Goroutine，用户级协程）、M（Machine，OS线程）、P（Processor，逻辑处理器，持有可运行的G队列）。M必须绑定一个P才能执行G，P的数量默认等于GOMAXPROCS（通常为CPU核心数）。G的创建、就绪、运行、阻塞四个状态转换由Go runtime管理。当G阻塞时（系统调用、channel等待），runtime会自动把M从P解绑，绑定到新的P或新建M，避免P空闲浪费CPU。

Go G-M-P 调度模型

        ┌────────────────────────────────┐
        │       GOMAXPROCS (P池)         │
        │  ┌────┐ ┌────┐ ┌────┐ ┌────┐│
        │  │ P1 │ │ P2 │ │ P3 │ │ P4 ││
        │  └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘│
        └────┼─────┼─────┼─────┼────┘
             │     │     │     │
        ┌────▼─┐ ┌─▼──┐ ┌▼───┐ ┌▼────┐
        │  M1 │ │ M2 │ │ M3 │ │ M4 │  OS线程
        └──────┘ └────┘ └────┘ └────┘
             │     │     │     │
        ┌────▼─────▼─────▼─────▼────┐
        │     G队列（Goroutine）      │
        │ G1, G2, G3, G4, ..., GN    │
        └─────────────────────────────┘
      

十、经验沉淀：7个生产级实战教训

10.1 教训1：池化虚拟线程是反面模式

某电商平台在2024年Q1把秒杀服务的200线程池改为newVirtualThreadPerTaskExecutor，但保留了200的并发限制，认为"虚拟线程也要做流控"。实际上虚拟线程的创建成本极低（300字节），任何并发限制都直接削弱M:N调度的核心优势。正确做法是去掉并发限制，让QPS决定虚拟线程数，JVM调度器负责映射到CPU核。

10.2 教训2：synchronized致Pin灾难

某支付系统在2024年Q2上线虚拟线程后出现间歇性P99飙升至30秒。JFR分析显示jdk.VirtualThreadPinned事件集中在支付核心链路，根因是库存服务的synchronized锁保护HashMap。改造为ConcurrentHashMap + ReentrantLock后，P99从30秒降至200ms。这是虚拟线程上线后最常见的故障模式，必须作为上线前的硬性门控。

10.3 教训3：CPU密集任务拖垮调度器

某数据中台服务把所有Spark计算任务提交到虚拟线程上，导致CPU密集的Shuffle阶段占满所有Carrier线程，对外提供的查询API全部饿死。治理方案：CPU密集任务提交到独立平台线程池（newFixedThreadPool），虚拟线程池仅承载I/O密集的查询请求。两个池的资源隔离让P99查询延迟从5秒降至100ms。

10.4 教训4：第三方JNI库Pin

某AI推理服务调用TensorFlow Java库的native方法做模型推理，每次推理平均200ms。虚拟线程被Pin在native调用上，Carrier被独占200ms，4个Carrier的理论并发从20个请求/秒降至20 QPS。治理方案：JNI推理调用提交到独立平台线程池（10个线程），虚拟线程只负责I/O编排。QPS恢复到800+。

10.5 教训5：ThreadLocal内存泄漏

某微服务在虚拟线程上线后出现堆内存持续增长，最终OOM。根因是用户上下文信息存储在ThreadLocal中，百万虚拟线程×每线程1KB ThreadLocal=1GB内存占用。治理方案：迁移到JDK21的Scoped Values（JEP 446），它是不可变的、生命周期与虚拟线程绑定，GC友好。ThreadLocal在虚拟线程下应当被Scoped Values替代。

10.6 教训6：jstack全量dump卡死

某SRE团队在故障排查时执行jstack命令，期望拿到所有线程栈。但百万虚拟线程的栈dump过程持续45秒，期间所有Carrier线程被冻结，整个服务对外不可用。治理方案：使用jcmd Thread.dump_to_file -format=plain（指定范围），或使用JFR的jdk.ThreadStart事件流式采样，禁止全量dump。

10.7 教训7：与Reactive框架冲突

某系统同时使用了Spring WebFlux（Reactive）和虚拟线程，导致线程调度出现两套体系互相拉扯。WebFlux的Scheduler把任务提交到虚拟线程上，虚拟线程又调用阻塞的JDBC，Reactive的背压机制完全失效。治理方案：二选一——要么WebFlux全程非阻塞+响应式数据库驱动，要么Servlet+虚拟线程+JDBC。不要混用。