Java 虚拟线程：Project Loom 并发模型原理与高并发实践

2. 使用专用 Executor（推荐方式）

此 Executor 为每个任务分配一个全新虚拟线程，无需手动管理池化，尤其适用于服务器场景。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        executor.submit(() -> processRequest());
    }
}

虚拟线程与结构化并发（Structured Concurrency）的结合尤为强大。JDK 21 引入的 StructuredTaskScope 将并发任务组织为树状结构，便于统一取消与异常传播。以并行调用多个下游服务为例：

String fetchProductDetails(Long productId) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        // 并发获取价格、库存、评论
        StructuredTaskScope.Subtask<String> priceTask = scope.fork(() -> queryPrice(productId));
        StructuredTaskScope.Subtask<Integer> stockTask = scope.fork(() -> queryStock(productId));
        StructuredTaskScope.Subtask<List<String>> reviewsTask = scope.fork(() -> queryReviews(productId));
        
        scope.join().throwIfFailed();
        return formatResponse(priceTask.get(), stockTask.get(), reviewsTask.get());
    }
}

此模式下，如果价格查询超时或失败，库存与评论查询会被立即中断，避免资源浪费。线程转储（thread dump）中也会显示清晰的父子关系，便于问题定位。

实践案例：高并发 Web 服务优化

考虑一个典型的 Spring Boot REST 服务，需要处理大量并发请求，每个请求涉及数据库查询 + 外部 API 调用 + 模板渲染。传统方式下，使用固定大小线程池（Tomcat 默认 200）容易出现队列积压。

启用虚拟线程后，只需简单配置：

# application.properties
spring.threads.virtual.enabled=true
server.tomcat.threads.max= # 可移除或设很大值

业务代码保持同步阻塞风格：

@RestController
public class ProductController {
    @Autowired
    private ProductService service;

    @GetMapping("/products/{id}")
    public ProductDetail getProduct(@PathVariable Long id) {
        // 阻塞式调用
        Product product = service.getProduct(id);      // DB
        Price price = externalApiClient.getPrice(id);  // HTTP
        List<Review> reviews = reviewRepository.findByProductId(id); // DB
        return new ProductDetail(product, price, reviews);
    }
}

在 10 万 QPS 压力测试中，使用虚拟线程的版本可轻松处理数万并发连接，而传统模式在 1000+ 并发时即出现延迟激增。关键在于：每个请求独占一个虚拟线程，阻塞时不占用载体线程，整体吞吐量大幅提升。

另一个典型场景是批量任务处理，如夜间报表生成：

void generateReports(List<Long> userIds) {
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        List<Future<Report>> futures = userIds.stream()
            .map(id -> executor.submit(() -> generateUserReport(id)))
            .toList();
        // 等待全部完成，或结合 StructuredTaskScope 实现短路
        for (Future<Report> f : futures) {
            try {
                f.get();
            } catch (Exception e) {
                log.error("Report failed", e);
            }
        }
    }
}

此方案可轻松并行处理上万用户报表，而不会耗尽系统资源。

常见误区与解决方案

误区 1：继续使用线程池池化虚拟线程 许多开发者出于习惯，将 newVirtualThreadPerTaskExecutor() 视为'无限线程池'，但仍尝试固定容量。结果适得其反，因为虚拟线程本就廉价，池化反而引入不必要的调度开销。 解决方案： 始终使用 Executors.newVirtualThreadPerTaskExecutor() 或直接 Thread.ofVirtual().start()，让 JVM 自由管理。

误区 2：滥用 ThreadLocal 缓存昂贵对象 传统线程池中，ThreadLocal 用于缓存 SimpleDateFormat 等非线程安全对象。但虚拟线程生命周期短且数量巨大，缓存会造成内存浪费。 解决方案： 优先使用不可变线程安全替代品，如 DateTimeFormatter 静态实例：

private static final DateTimeFormatter FMT = DateTimeFormatter.ISO_DATE_TIME;

误区 3：忽略 pinning 问题 当虚拟线程在 synchronized 块内执行长时间阻塞操作时，会发生 pinning，导致载体线程无法释放。 解决方案： 使用 ReentrantLock 替换 synchronized，尤其在 I/O 操作周围；开启 -Djdk.tracePinnedThreads=full 诊断 pinning 热点。

误区 4：将虚拟线程用于纯 CPU 密集任务 虚拟线程在计算密集场景下并无明显优势，甚至因调度略有下降。 解决方案： CPU 密集任务仍使用平台线程或 ForkJoinPool.commonPool()。

总结

虚拟线程作为 Project Loom 的核心成果，标志着 Java 并发模型从'资源稀缺'向'资源充裕'的范式转变。它让开发者能够以最自然的同步阻塞风格应对高并发需求，同时保持极高的吞吐量与资源效率。在云原生、微服务、Serverless 等场景下，虚拟线程已成为构建高性能后端服务的首选方案。

当然，任何技术都有适用边界。虚拟线程最擅长的仍是 I/O 密集型工作负载，对于极致低延迟或重计算场景，仍需结合其他工具。