Java 虚拟线程概览
虚拟线程如何改变阻塞式并发的成本模型：适用 IO 密集任务、与平台线程/池化策略的边界。
#concept
#growing
#dev
#java
[!info] related notes
Java 虚拟线程概览
这个概念为什么出现
传统一请求一平台线程在高并发阻塞 IO 下成本高；回调/响应式又难写。虚拟线程（Project Loom，现代 JDK 提供）让“阻塞式代码风格”在大量并发 IO 下更可行，但仍要理解钉住（pinning）、池化与适用边界。
[!abstract] 一句话理解 虚拟线程是由 JVM 调度的轻量线程，适合大量阻塞式 IO 并发；不自动让 CPU 密集任务更快，也不消灭对共享可变状态同步的需要。
最小可运行示例
场景：验证单个模拟 IO 任务运行在虚拟线程上（需 JDK 21+）
import java.util.concurrent.*;
public class VirtualThreadDemo {
public static void main(String[] args) throws Exception {
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
Future<String> f = executor.submit(() -> {
Thread.sleep(50); // 模拟阻塞 IO
return "ok-on-" + Thread.currentThread().isVirtual();
});
System.out.println(f.get());
}
}
}建议运行（JDK 21+）：
javac VirtualThreadDemo.java && java VirtualThreadDemo期望输出：
ok-on-trueJava 21 将虚拟线程正式交付；本例只验证入口与线程类型，不是吞吐压测。try-with-resources 会在退出时关闭 Executor 并等待任务结束；这不是有截止时间的强制取消。
结合场景再看三个关注点
- per-task 虚拟线程替代“巨型平台线程池扛阻塞”的老套路。
- 同步与线程局部语义仍在，设计不能变放飞。
- CPU 密集仍要限制并行度。
核心概念与准确模型
1. 平台线程 vs 虚拟线程
| 平台线程 | 虚拟线程 | |
|---|---|---|
| 成本 | 相对高 | 相对低（实现相关） |
| 适合 | 计算、少量并发 | 海量阻塞 IO |
| 调度 | OS | JVM 承载 |
2. 使用入口
Thread.ofVirtual()Executors.newVirtualThreadPerTaskExecutor()
3. 限制意识
- Java 21 中，在 synchronized 区域内阻塞可能钉住载体线程；Java 24 的 JEP 491 消除了这类监视器相关 pinning。
- JEP 491 后仍存在本地代码回调 Java 再阻塞等 pinning 情况，不能一概认为完全消失。\
- 不应池化虚拟线程来限流；per-task Executor 不限制任务数，数据库连接、下游配额等仍需 Semaphore 或资源池约束。
- 虚拟线程是 daemon，不能只提交任务就假设它会阻止 JVM 退出；需显式等待任务生命周期。\
边界情况与反直觉行为
- 在虚拟线程里跑重 CPU 循环会占用载体。
- 旧库做线程池缓存假设可能失效。
- 调试工具/线程 dump 形态变化。
常见误区
[!warning] 常见误区：开了虚拟线程就不用管锁 数据竞争规则不变。
工程实践
- IO 密集服务评估虚拟线程。
- 仍隔离 CPU 池。
- 压测对比平台线程池。
- 关注 JDK 版本与已知 pinning 报告。
本节总结
- 虚拟线程改变阻塞并发成本
- 风格可同步化，正确性不打折
- 版本与场景决定是否采用
自测题
- 虚拟线程主要优化什么？
- 为什么说它不是自动并行化？
参考答案
- 大量阻塞式并发的线程成本与编程模型。
- 不增加 CPU 算力；计算任务仍受核数与算法限制。
延伸阅读与资料来源
| 资料 | 类型 | 支撑内容 |
|---|---|---|
| JEP 444 Virtual Threads | JEP | 设计与语义 |
| JEP 491 | JEP（Java 24） | synchronized 相关 pinning 改进 |
| Virtual Threads (Oracle) | 文档 | 用法 |
Digital Biome