ProjectLoom：Java并发新纪元

Project Loom 是 Java 并发编程的范式革命，它通过轻量级虚拟线程将百万级并发拉回简洁直观的同步编码风格——只需升级至 JDK 21+，改用 Thread.ofVirtual() 或 newVirtualThreadPerTaskExecutor() 启动任务，配合 StructuredTaskScope 精确管控生命周期，即可让阻塞 I/O 自动卸载、零成本挂起，彻底摆脱“线程昂贵”的历史枷锁；但真正的挑战不在技术适配，而在于重构团队根深蒂固的并发心智模型：当线程如对象般廉价创建与消亡，监控、诊断与协作方式都将迎来一场静默却深刻的重写。

Project Loom 不是“又一个并发优化”，而是把 Java 并发从“省着用线程”变成“随便开线程”的分水岭。它让百万级并发回归同步写法，代价只是升级 JDK 21+ 并改几行启动逻辑。

怎么启用虚拟线程：别碰 Thread 构造器，用工厂方法

直接 new Thread 创建的是平台线程（Platform Thread），哪怕在 JDK 21+ 也默认不走虚拟线程。必须显式调用工厂 API：

• Thread.ofVirtual().name("vt-1").start(Runnable) —— 单次启动，适合简单任务
• Executors.newVirtualThreadPerTaskExecutor() —— 推荐用于批量任务，自动管理生命周期，记得 try-with-resources
• 千万别用 new Thread(Runnable) 或 Executors.newCachedThreadPool()，它们和虚拟线程无关

常见错误：在 Spring Boot 3.0+ 中手动 new Thread 处理 HTTP 请求，结果还是卡在平台线程池里，QPS 毫无提升。

阻塞 I/O 自动挂起：为什么 Thread.sleep() 和数据库调用不拖垮系统

虚拟线程的魔法不在“快”，而在“卸载”。当它执行 Thread.sleep()、Socket.read()、Connection.prepareStatement() 等阻塞操作时，JVM 会立刻把它从当前载体线程上“卸载”，腾出 CPU 给其他就绪的虚拟线程——整个过程不涉及 OS 调度，开销仅约 23ns。

• 这意味着你可以放心写同步代码，比如 orderService.place(); paymentClient.call(); notifyUser();，而不会因一次远程调用阻塞整个线程
• 但前提是：底层库支持中断或非阻塞语义。旧版 MySQL Connector/J 8.0.23 之前不响应虚拟线程中断，会导致挂起失效，必须升级
• 日志中看到 VirtualThread[#xx]/runnable 是正常状态；若长期显示 /blocked，说明某处阻塞未被 JVM 识别（如 native 调用、自旋锁）

结构化并发不是可选项：不用 StructuredTaskScope 就容易漏任务

传统 ForkJoinPool 或 CompletableFuture 启动的子任务一旦抛异常或被取消，父任务可能提前结束，子任务却还在后台跑——这就是任务泄漏。Loom 强制你用作用域管理生命周期：

• 用 try (var scope = new StructuredTaskScope.ShutdownOnFailure()) 包裹所有并发子任务
• 每个子任务通过 scope.fork(() -> ...) 启动，scope.join() 阻塞等待全部完成或任一失败
• 作用域退出时，未完成的子任务自动取消，且异常统一汇聚到 scope.throwIfFailed()
• 别试图在 scope 外保存 Future 或 Thread 引用，它们会在 scope 关闭后失效

最容易被忽略的一点：Spring 的 @Async 默认不感知结构化作用域，混合使用时需显式传递 StructuredTaskScope 实例，否则并发控制会脱节。

真正难的不是写对那几行 ofVirtual() 或 StructuredTaskScope，而是说服团队放弃“线程很贵”的肌肉记忆——当每毫秒都在创建销毁线程成为常态，监控指标、线程 dump、GC 日志的解读方式全得重来。

到这里，我们也就讲完了《ProjectLoom：Java并发新纪元》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！