最近我给一个 Spring Boot 订单查询接口做虚拟线程灰度，第一版开关一打开，线程数量是下来了，但 p99 没怎么好看，数据库连接池还出现了排队。这个结果不意外：Java 21 的 virtual threads 能把“等 I/O 的线程成本”降下来，但不会把下游资源变多，也不会让 CPU 代码突然变快。
所以这篇不写成官方说明书。我按生产落地的顺序讲：什么时候值得开、Spring Boot 怎么开、为什么不能池化虚拟线程、连接池和 synchronized 怎么排查、上线前要看哪些指标。资料我核了 OpenJDK JEP 444、JEP 491 和 Spring Boot 官方文档，但正文按工程经验重新组织。
先判断场景：虚拟线程解决的是等待成本，不是执行速度
我会先看接口画像。如果请求大部分时间花在 JDBC、HTTP、Redis、对象存储这类阻塞 I/O 上，虚拟线程通常值得试；如果接口热点是 JSON 大对象转换、加解密、复杂规则计算、报表聚合，那开虚拟线程基本救不了 p99。
JEP 444 讲得很清楚：虚拟线程适合高并发、非 CPU-bound 的服务端任务。它保留同步代码的可读性，让一个请求仍然像一条顺序调用链，而不是为了扩吞吐把业务拆成一堆回调。
Spring Boot 怎么开：先灰度，不要全站一把梭
Spring Boot 支持通过配置启用虚拟线程。我的做法是先给低风险接口单独灰度一批实例，而不是全量打开：
spring:
threads:
virtual:
enabled: true
打开以后别急着庆祝。你要看的是同等流量下平台线程、虚拟线程、JDBC 连接池等待、HTTP 客户端连接池等待、错误率和 p95/p99。吞吐涨了但连接池排队更严重，本质是把瓶颈从线程池搬到了资源池。
第一个坑：不要把虚拟线程重新池化
老线程池时代，我们用线程池大小顺手做了并发控制。到了虚拟线程，这个习惯要改。虚拟线程便宜，JEP 444 明确建议不要池化虚拟线程；如果你想限制下游并发，应该限制资源访问，而不是限制线程数量。
比如订单服务最多只允许 80 个并发请求打到某个老接口，那就用 Semaphore、Bulkhead 或网关限流表达这个资源边界。线程是承载任务的工具，不再是资源保护阀。
第二个坑：synchronized 和 native 调用可能让 carrier 被占住
虚拟线程阻塞在很多 JDK I/O 操作上时可以卸载 carrier，但不是所有阻塞都一样。老版本里 synchronized 临界区和某些 native 调用可能造成 pinning，也就是虚拟线程把底层平台线程占住。JEP 491 的目标就是减少 synchronized 场景下的 pinning，但这不代表你可以忽略锁热点。
我的排查顺序是：先用 JFR 看 VirtualThreadPinned 相关事件，再看锁竞争和业务栈。如果热点锁只是保护一个本地 Map，可以考虑缩小临界区或换成更明确的并发结构；如果锁里包着远程调用，那基本就是事故预备役。
第三个坑：ThreadLocal 大对象会把便宜线程变贵
虚拟线程支持 ThreadLocal，这对兼容老框架是好事。但如果你把大对象、数据库连接、用户上下文全集都塞进 ThreadLocal，每个请求一个虚拟线程时，内存压力会非常难看。ThreadLocal 只放必要的小上下文，跨层传递能显式参数就显式参数。
上线检查清单
- 接口是否 I/O 等待占主导，CPU 利用率是否还有余量？
- JDBC、HTTP、Redis 等连接池是否重新评估，是否有排队指标？
- 是否有用固定线程池包装虚拟线程的代码？如果有，为什么？
- JFR 是否出现明显 VirtualThreadPinned，栈顶在哪里？
- ThreadLocal 是否存了大对象、连接或不可控缓存？
- 灰度失败时是否能一键回滚到平台线程执行模式？
最后聊两句
虚拟线程是 Java 后端这几年最值得认真落地的能力之一，但它不是“打开就变快”的魔法开关。我的经验是：同步代码可以保留，线程池思维要更新，资源边界要重新画清楚。
如果你的服务是典型 I/O 密集型，Spring Boot + Java 21 的组合很值得灰度；如果你的瓶颈在 CPU、锁和下游配额，虚拟线程只会更快地把这些问题暴露出来。暴露问题不是坏事，前提是你上线前已经准备好观测、限流和回滚。
