《Java 演进之路》系列 · 第 15 篇

虚拟线程预览来了：JDK 19 的并发新可能

以前写并发代码，总觉得像在走钢丝；现在用虚拟线程，感觉像在平地上跑步——还是那种不用看路的平路。

2022年9月JDK 19发布时，我正好在调试一个高并发场景下的性能瓶颈。看到OpenJDK宣布虚拟线程进入预览，立刻意识到这可能是解决一类老问题的新思路。

和JDK 18一样，它不是LTS，生命周期只有半年。但千万别把它当普通的“过渡版本”！JDK 18是帮我们解决“今天的麻烦”，JDK 19是直接给我们看“明天的样子”——它把Project Loom搞了好几年的虚拟线程和结构化并发，第一次以预览版的形式放出来了。

说实话，看到这两个特性的第一眼，我就觉得：Java并发编程，可能真的要变天了。

📌 JDK 19 官方特性总览

先提一句官方背景哈：JDK 19的所有新特性都是基于 JSR 394（《Java SE 19 发布规范》） 来实现的。

大概梳理了下，它的改动主要是这几块我比较关心： 第一块肯定是Project Loom的两个大杀器——虚拟线程和结构化并发，终于放预览版了，邀请整个社区一起试错； 第二块是之前的孵化器项目继续推进——Foreign Function & Memory API（FFM）又迭代了一版，向量API也优化了； 第三块是清理历史包袱——那个早就没人用的Applet API，终于被正式移除了，标准库又轻了一点。

能感觉到，Java这次是真的在为云原生、高并发的时代做准备了。

1. 虚拟线程（预览版，JEP 425）

说真的，这是我近几年看到Java最值得关注的特性之一。

先讲个常见的痛点：在处理大量I/O密集型任务时，传统的线程模型要么资源消耗巨大，要么就得引入复杂的异步编程模型。代码的可读性和维护性往往会因此大打折扣。

那时候我就在想：要是能用同步的写法，获得接近异步的吞吐能力，该多好？

虚拟线程就干了这件事！你可以把它想象成JVM给我们“批发”的线程——以前我们是直接向OS“零售”买线程，贵得要死，买几百个就没钱了；现在JVM先向OS批发一批“载体线程”，然后我们可以在上面创建无数个虚拟线程，便宜到像不要钱。

说下我的初体验：我用Spring Boot写了个最简单的接口，里面睡1秒，然后返回“ok”。

• • 以前用普通线程池，设200个核心线程，压测工具（用的是JMeter）开到500并发，响应时间就直接炸到5秒以上；
• • 后来加了--enable-preview，把线程池换成Executors.newVirtualThreadPerTaskExecutor()，同样的代码，压到10000并发，响应时间还是1秒多一点！
• • 最关键的是：代码一行异步回调都没写，就是普通的Thread.sleep()，连CompletableFuture都没用。

那一刻我真的有点懵——感觉自己以前学的Netty、Reactor这些，好像突然就“不香”了？

当然，我也知道它现在只是预览版：API可能还会变，有些地方（比如synchronized块里的IO）还会“钉住”载体线程，影响性能。生产环境肯定不敢用，但光是在本地玩一玩，就已经足够让我兴奋了。

对我来说，它最大的意义不是“性能提升了多少”，而是终于不用再跟异步回调死磕了。以后写并发代码，终于可以把精力放在业务逻辑上，而不是“怎么把回调串起来”上。

2. 结构化并发（孵化版，JEP 428）

如果说虚拟线程解决了“能不能创建很多线程”的问题，那结构化并发就是解决“创建了很多线程后，怎么管好它们”的问题。

再讲个常见的坑：在编写并行任务时，如果父任务因异常提前退出，子任务很容易变成“孤儿线程”在后台继续运行，导致资源泄露甚至逻辑错误。

那时候我就在想：要是父线程挂了，子线程能自动跟着挂，该多好？

结构化并发就干了这件事！它用一个StructuredTaskScope把所有子任务“框”在一个作用域里——就像try-with-resources管资源一样，出了这个作用域，所有子任务要么已经完成，要么已经被取消，绝对不会有“孤儿线程”。

我后来把那个批量导入工具用结构化并发重写了一下，代码变成了这样：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<List<User>> users = scope.fork(() -> batchQueryUsers(ids));
    Future<List<Order>> orders = scope.fork(() -> batchQueryOrders(ids));
    scope.join(); // 等所有任务
    scope.throwIfFailed(); // 只要有一个任务挂了，这里直接抛，剩下的自动取消
    // 合并 users 和 orders...
}

写完我特意试了试：故意让查用户信息的接口抛异常，结果查订单信息的线程真的立刻就停了，数据库连接也马上释放了——那一刻我真的觉得，以前踩的那些坑，终于有人帮我填上了。

当然，它现在还是孵化版，API比虚拟线程还不稳定。但它和虚拟线程真的是天生一对：虚拟线程让我们能创建很多线程，结构化并发让我们能安全地管理这些线程。

3. Foreign Function & Memory API（第三孵化器，JEP 424）

FFM API又来了！这是它在JDK 17、JDK 18之后的第三次迭代——感觉OpenJDK社区这次是真的想把JNI换掉。

我特意抽了一个晚上试了试：用它调了C标准库的strlen函数，算一个字符串的长度。 说下感受：

• • 比JDK 18的版本确实顺手了一点，之前分散的MemorySegment和MemoryAddress现在整合得更自然了；
• • 但还是有点复杂——为了调一个strlen，我写了快20行代码，还要记一堆布局（Layout）的概念；
• • 不过比JNI还是强太多了：至少不用写C代码，不用生成头文件，不用跨平台编译。

虽然我自己平时用不到（我主要写Web服务），但能感觉到OpenJDK在认真听反馈——每次迭代都在简化API。对于那些需要和C/C++库深度交互的领域（比如游戏引擎、数据库驱动、科学计算），这真的是巨大的利好：以后终于不用再跟JNI的“地狱级”代码打交道了。

它的持续孵化，也让我觉得Java不只是想做“Web语言”，还想在系统编程领域分一杯羹。

🧩 为什么关注 JDK 19？

• • 并发模型的拐点：虚拟线程和结构化并发的预览，标志着Java并发编程可能迎来自java.util.concurrent以来最大的一次范式转移。
• • 短期版本的威力：它再次证明，非LTS版本是承载高风险、高回报创新的最佳载体。没有这些短期版本的快速试错，我们就看不到如此激进的变革。
• • 面向云原生：轻量级的虚拟线程天生适合云环境，能极大地提升单机的资源利用率，降低运维成本。
• • 生态的延续性：Vector API、FFM API等项目的持续推进，展示了Java生态强大的生命力和前瞻性。

🧱 其他重要平台增强

• • Vector API (第四孵化器, JEP 426)：又双叒叕孵化了一轮！这次的重点是增强了对浮点运算和跨平台兼容性的支持。虽然在我的M1上还是跑不起来，但至少文档看起来更友好了。
• • 预览 switch 的记录模式和数组模式 (JEP 405)：终于！在JDK 18的switch模式匹配基础上，现在可以直接解构record和数组了！虽然还是预览版，但这才是模式匹配该有的样子。case Point(int x, int y) -> ... 写起来简直不要太爽。
• • 移除 Applet API (JEP 423)：那个早已被时代抛弃的Applet，终于从Java标准库中被正式移除了。从此，Java的安全模型可以更专注、更精简，历史的包袱又轻了一分。

✅ 总结

JDK 19通过JSR 394，完成了一次大胆而深刻的“投石问路”。它没有满足于渐进式的改进，而是直接将 Project Loom 的核心——虚拟线程与结构化并发——推向了聚光灯下。这不仅仅是一两个新API的加入，而是一场关于如何思考和编写并发程序的哲学变革。JDK 19或许只是一个预览，但它所描绘的未来图景——用简单的同步代码驾驭海量并发——已经足够清晰和诱人。它告诉我们，Java这门古老的语言，依然拥有颠覆自我、引领未来的勇气和能力。

📢 延伸阅读建议

• • JSR 394: Java SE 19 规范[1]
• • OpenJDK JDK 19 官方页面[2]
• • JEP 425: Virtual Threads (Preview)[3]
• • JEP 428: Structured Concurrency (Incubator)[4]
• • JEP 424: Foreign Function & Memory API (Third Incubator)[5]

引用链接

[1] JSR 394: Java SE 19 规范: https://www.jcp.org/en/jsr/detail?id=394 [2] OpenJDK JDK 19 官方页面: https://openjdk.org/projects/jdk/19/ [3] JEP 425: Virtual Threads (Preview): https://openjdk.org/jeps/425 [4] JEP 428: Structured Concurrency (Incubator): https://openjdk.org/jeps/428 [5] JEP 424: Foreign Function & Memory API (Third Incubator): https://openjdk.org/jeps/424