[!info] 关联笔记

• 所属 MOC：并发 · 学习路线
• 前置概念：线程 · 线程池 · CompletableFuture
• 后续概念：服务工程 · HTTP 服务
• 容易混淆：虚拟线程不是自动并行加速 CPU 计算

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-true

若 JDK 过旧，编译/API 不可用——以本机版本为准。

结合场景再看三个关注点

1. per-task 虚拟线程替代“巨型平台线程池扛阻塞”的老套路。
2. 同步与线程局部语义仍在，设计不能变放飞。
3. CPU 密集仍要限制并行度。

核心概念与准确模型

1. 平台线程 vs 虚拟线程

	平台线程	虚拟线程
成本	相对高	相对低（实现相关）
适合	计算、少量并发	海量阻塞 IO
调度	OS	JVM 承载

2. 使用入口

• Thread.ofVirtual()
• Executors.newVirtualThreadPerTaskExecutor()

3. 限制意识

• 某些本地帧/同步可能 pinning（随版本改善）
• 不适合盲目替代所有池

边界情况与反直觉行为

1. 在虚拟线程里跑重 CPU 循环会占用载体。
2. 旧库做线程池缓存假设可能失效。
3. 调试工具/线程 dump 形态变化。

常见误区

[!warning] 常见误区：开了虚拟线程就不用管锁 数据竞争规则不变。

工程实践

1. IO 密集服务评估虚拟线程。
2. 仍隔离 CPU 池。
3. 压测对比平台线程池。
4. 关注 JDK 版本与已知 pinning 报告。

本节总结

• 虚拟线程改变阻塞并发成本
• 风格可同步化，正确性不打折
• 版本与场景决定是否采用

自测题

1. 虚拟线程主要优化什么？
2. 为什么说它不是自动并行化？

参考答案

1. 大量阻塞式并发的线程成本与编程模型。
2. 不增加 CPU 算力；计算任务仍受核数与算法限制。

延伸阅读与资料来源

资料	类型	支撑内容
JEP 444 Virtual Threads	JEP	设计与语义
Virtual Threads (Oracle)	文档	用法