虚拟线程吞吐量（17,901 ops/s）显著高于平台线程（8,432 ops/s），响应延迟更低（56ms vs 118ms），GC暂停更少（3次 vs 12次），且避免了“unable to create native thread”错误。
用 JMH 测 Executors.newVirtualThreadPerTaskExecutor() 和固定线程池的吞吐量差异
直接对比才是最可靠的评估方式。JMH 是 JDK 官方推荐的微基准测试工具，能排除 JIT 预热、GC 干扰等噪声，测出真实吞吐量（ops/s）。关键不是“能不能跑”，而是“单位时间能完成多少次阻塞型任务”。
常见错误现象：OutOfMemoryError: unable to create native thread 在平台线程测试中频繁出现，但虚拟线程下几乎不发生；或平台线程吞吐卡在 8k ops/s 左右就上不去，而虚拟线程轻松突破 17k+ —— 这说明瓶颈已从线程资源转移到 I/O 或 CPU 本身。
- 必须模拟真实阻塞行为，比如
Thread.sleep(100)或HttpClient.send()，纯计算任务无法体现虚拟线程优势 - 平台线程侧要用
Executors.newFixedThreadPool(200)这类固定池，避免用newCachedThreadPool()（它会无限创建平台线程，掩盖真实瓶颈） - 虚拟线程侧统一用
Executors.newVirtualThreadPerTaskExecutor()，不要手动 new Thread().startVirtualThread()，否则无法体现结构化并发的调度收益 - JVM 参数要一致：至少加
-Xmx4g -XX:+UseZGC，避免 GC 成为干扰项
观察 GC 暂停次数和堆外内存变化
虚拟线程本身不直接分配堆内存，但它的栈帧存于堆外（off-heap），且每个线程挂起/恢复依赖 Continuation 对象 —— 这些对象生命周期短、数量大，会显著影响 GC 行为。
使用场景：当你发现吞吐量提升但响应延迟毛刺变多，大概率是 ZGC 或 Shenandoah 的回收压力被虚拟线程放大了。
- 启动时加
-Xlog:gc*,safepoint:file=gc.log:time,tags，压测前后比对GC pause次数和平均耗时 - 用
jcmd <pid> VM.native_memory summary查看Internal和Thread区域内存增长 —— 虚拟线程的栈内存会计入Thread，但远低于平台线程（1KB vs 1MB） - 若
Internal区暴涨，可能是 Continuation 缓存未及时回收，需检查是否遗漏try-with-resources关闭ExecutorService
监控底层平台线程（Carrier Thread）利用率
虚拟线程不等于“没有线程竞争”。所有虚拟线程最终都运行在少量 Carrier Thread 上，如果这些线程长期被 CPU 密集型任务占满，虚拟线程就会排队等待，吞吐反而下降。
容易踩的坑：把大量 Stream.parallel() 或加密计算丢进虚拟线程 —— 这类任务本就不该用虚拟线程。
- 用
jstack <pid>观察线程名：以ForkJoinPool或CarrierThread开头的是平台线程，以VirtualThread开头的是用户线程 - 用
top -H -p <pid>看各线程 CPU 占用，若几个 Carrier Thread 持续 95%+，说明存在 CPU 瓶颈，需把计算型任务剥离到专用ForkJoinPool - Spring Boot 3.2+ 默认启用虚拟线程，但
@Async方法若没显式指定TaskExecutor，仍可能落到平台线程池里，导致误判
别忽略应用框架层的适配成本
吞吐量数字好看，不代表上线就稳。Spring WebMvc、Netty、Hibernate 等组件对虚拟线程的支持程度不一，有些地方会隐式阻塞 Carrier Thread。
例如：Spring Data JDBC 在事务提交时调用 Connection.commit()，若驱动未适配 Loom，就会让整个 Carrier Thread 卡住 —— 此时吞吐量可能不升反降。
- 优先验证 HTTP 层：用
WebClient替代RestTemplate，确保底层用的是虚拟线程友好的HttpClient - 数据库连接池必须支持虚拟线程，HikariCP 5.0+ 和 Apache DBCP3 2.9.0+ 才真正兼容，旧版本会退化为平台线程调度
- 日志框架注意
AsyncAppender的队列堆积风险：虚拟线程并发高，日志写入若未异步化，会拖慢 Carrier Thread
