☕ 编程 · Java

🔥 虚拟线程出来四年了，Java 圈却没怎么炸锅，不是技术不行，而是大家心里门儿清：它解决的是 I/O 场景，很多老业务压根用不上。

一、虚拟线程到底解决了什么问题

虚拟线程从 JDK 21 正式转正，到 JDK 25 已经过了两年。它最直观的卖点，就是让 I/O 密集型应用能轻松扛住海量并发——单条虚拟线程内存才 1 到 2KB，而平台线程默认栈就要 1MB 左右。同样是 10 万并发，传统线程池可能把堆外内存吃到 3GB 以上，虚拟线程只要两三百兆。

原理上也讲得通：虚拟线程采用 M:N 调度，大量虚拟线程由少量载体线程复用执行，遇到数据库、HTTP 这类阻塞调用就自动挂起让出，代码不用改成异步。这正是它最大的魅力——开发者几乎零改造就能拿到接近异步编程的吞吐量。

二、为什么 Java 圈反而没那么热情

可现实是，圈里讨论的热度远没有想象中高。原因很简单：虚拟线程只对 I/O 密集型业务有奇效，CPU 密集型场景基本没收益。很多老项目的瓶颈根本不在线程，换成虚拟线程自然是"感觉不出来"。更麻烦的是迁移有坑——像 HikariCP、Caffeine、Apache HttpClient 这些库早年都在 I/O 路径里用 synchronized，高并发下会"钉住"载体线程导致死锁，Netflix 甚至因此出过生产事故。

好在 JDK 25 作为首个修复 pinning 问题的 LTS 版本，把 synchronized 钉住这个老大难从源头解决了，相关组件也都出了虚拟线程兼容版本。但对大多数团队来说，升级本身也是成本，收益不明显的项目自然按兵不动。

三、虚拟线程真的该上吗

业内主流判断其实挺清醒：I/O 密集就上，CPU 密集就老实待线程池。如果服务大部分时间在等数据库、等接口、等消息队列，虚拟线程能明显压低尾部延迟、省内存；如果是在纯跑计算，换虚拟线程纯属折腾。混合负载则建议把 CPU 重活显式丢回有上限的平台线程执行器。

还有个容易踩的坑：虚拟线程太便宜，容易一次性创建百万级任务，但数据库连接、文件描述符这些资源还是有限的，不配合信号量做限流，反而会从"线程池天然限流"变成"资源池被打爆"。虚拟线程不是银弹，是给对场景的一把好刀。

综合 javacodegeeks、CSDN、OpenJDK loom-dev 社区报道 | 2026-08-26