project loom 是 java 并发的分水岭，使百万级并发回归同步写法；需用 thread.ofvirtual() 或 newvirtualthreadpertaskexecutor() 启用虚拟线程，避免 new thread；阻塞操作自动卸载，开销仅约 23ns；必须用 structuredtaskscope 管理任务生命周期。
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。
立即学习“Java免费学习笔记（深入）”；
- 这意味着你可以放心写同步代码，比如
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 日志的解读方式全得重来。
