JDK 25 长期支持周期下，虚拟线程应用进入哪一阶段

JDK 25 的长期支持身份，把虚拟线程推到了一个更明确的位置：它已经不是“要不要试试看”的新 API，而是可以进入生产迁移计划的并发基础能力。这个判断并不等于所有 Java 服务都应立刻切换。真正变化的是，企业终于有了一个适合长期维护的版本基线，可以把框架兼容、监控工具、容量测试和回退方案放进同一轮升级。

JDK 25 官方文档：https://docs.oracle.com/en/java/javase/25/

JDK 25 改变的是采用周期，不是虚拟线程的基本定义

虚拟线程由 JEP 444 在 JDK 21 正式交付。它仍然是 java.lang.Thread，但不与某个操作系统线程永久绑定。遇到受支持的阻塞 I/O 时，虚拟线程可以卸载，让承载它的平台线程去运行其他任务。官方定位一直很清楚：它服务于高吞吐并发应用，尤其是大量任务都在等待网络、数据库或队列的场景。

JDK 24 又通过 JEP 491 改善了 synchronized 相关的虚拟线程固定问题。到了 JDK 25，团队获得的是包含这些前序改进的 LTS 基线，以及一套更完整的创建、调度、诊断和采用指南。Oracle 当前支持路线图把 Java SE 25 列为 LTS，GA 时间为 2025 年 9 月，商业 Premier Support 计划延续到 2030 年 9 月，Extended Support 计划到 2033 年 9 月。

先看请求在等待什么，再决定是否迁移

一个典型候选是同步 MVC 服务：每个请求依次访问数据库、缓存和下游 HTTP 服务，大部分时间花在等待 I/O。过去为了避免平台线程长期被占用，团队会扩大线程池或改成异步回调；虚拟线程则允许继续使用顺序清晰的同步代码，同时承载更多并发任务。

反过来，如果任务长期占用 CPU，例如视频编码、压缩、密码计算或大规模内存扫描，增加虚拟线程数量不会提升处理器能力。Oracle 的 JDK 25 文档也明确指出，虚拟线程不是“更快的线程”：它解决的是吞吐扩展，不是单请求延迟。CPU 密集任务仍应按核心数控制并行度。

这里可以用一个简单问题筛选：高峰时，线程是在运行，还是在等外部资源？如果大部分线程处于 Socket、JDBC、队列或文件 I/O 等待，虚拟线程值得灰度；如果 CPU 已经持续饱和，先优化算法、批处理和并行度。

线程模型从“共享工人”变成“一个任务一个线程”

迁移后的核心不是把固定线程池的大小从 200 改成 20000，而是停止用线程池管理虚拟线程。官方建议让每个并发任务拥有自己的虚拟线程，例如使用 Executors.newVirtualThreadPerTaskExecutor()。虚拟线程本身不是稀缺资源，不需要池化。

真正稀缺的对象仍要单独治理。数据库连接池只有 50 个连接，就让连接池承担并发边界；下游接口只允许 100 个并发请求，就用 Semaphore 做限流。不要用“虚拟线程池大小”同时表达任务数量和资源容量，否则系统看似换了线程模型，背压语义却仍旧混在一起。

剩余风险已经从 synchronized 转向应用结构

JDK 24 之后，因 synchronized 导致的常见固定问题大幅收窄，但这不代表固定完全消失。JDK 25 官方文档仍指出，虚拟线程执行 native 方法或 foreign function 时可能固定在承载线程上。涉及本地库、JNI 或外部函数接口的服务，需要在真实调用路径上观察，而不是只看 Java 业务代码。

另一个更常见的问题是 ThreadLocal。它仍然可用，适合保存请求上下文，但不适合缓存昂贵的可复用对象。平台线程池只有几十个线程时，每线程缓存的对象数量有限；如果每个任务都创建虚拟线程，同样的写法可能变成成千上万个对象。日志上下文、事务上下文可以保留，格式化器、客户端或大缓冲区缓存则应重新检查。

还要避免把已经高度异步化的调用链和虚拟线程机械叠加。虚拟线程最能发挥价值的是简单同步、阻塞 I/O、一个任务一条调用栈。若框架内部仍大量切换异步执行器，既增加理解成本，也可能保留针对少量池线程设计的 ThreadLocal 假设。

观测指标要跟着任务模型一起改变

平台线程时代，线程池活跃数、队列长度和拒绝次数是常见指标。虚拟线程时代，任务不再排队等待某个固定工人，观测重点应改为：并发任务数、外部资源等待时间、连接池等待、信号量等待、请求取消、堆内存和载荷下的吞吐。

JDK Flight Recorder 提供虚拟线程相关事件，jcmd 也能生成包含平台线程和虚拟线程的线程转储。JDK 25 文档列出的 jdk.VirtualThreadStart、jdk.VirtualThreadEnd、jdk.VirtualThreadPinned 和 jdk.VirtualThreadSubmitFailed 可以帮助定位启动、固定和资源异常。事件数量可能很大，生产环境要按问题开启和采样，不能照搬平台线程时代的全量采集习惯。

JDK 25 下更稳妥的采用顺序

1. 选一条 I/O 等待明显的同步链路。避免先拿 CPU 密集批任务做证明。
2. 记录旧基线。保存吞吐、P95/P99、平台线程数、连接池等待、CPU、堆内存和错误率。
3. 改成每任务一个虚拟线程。保持业务语义不变，先不叠加结构化并发等其他改造。
4. 拆开资源限流。数据库、下游接口和文件句柄分别使用自己的池或信号量。
5. 检查 ThreadLocal 与本地调用。重点查昂贵对象缓存、JNI、foreign function 和不可取消阻塞。
6. 小流量灰度并保留回退。同一应用构建保留平台线程执行器开关，指标异常时能快速切回。

这套顺序的目标不是证明“虚拟线程一定更快”，而是确认在相同业务语义下，服务能否用更简单的同步代码承载更高并发，同时不把压力无上限地推给数据库和下游系统。

延伸问答

JDK 25 才能使用虚拟线程吗？

不是。虚拟线程在 JDK 21 已正式交付。JDK 25 的主要意义是新的 LTS 采用基线，并继承后续版本的实现改进。

升级到 JDK 25 后会自动变成虚拟线程吗？

不会。应用或框架必须明确创建虚拟线程，原有平台线程和线程池不会被自动替换。

虚拟线程能降低接口 P99 吗？

不保证。它主要提升等待型负载下的并发吞吐；单次下游调用耗时、锁竞争和数据库慢查询仍会影响 P99。

还需要数据库连接池吗？

需要。虚拟线程不是数据库连接，连接池仍负责管理有限连接并形成自然背压。

还要关注固定问题吗？

要，但重点已变化。同步锁导致的常见固定在 JDK 24 后显著改善，native 方法和 foreign function 等路径仍应通过 JFR 和真实负载观察。

所以，JDK 25 下的虚拟线程已经进入“可规模化采用，但必须工程化治理”的阶段。API 试用期基本结束，接下来比语法更重要的是负载选择、资源边界、可观测性和组织层面的升级节奏。