Java 21 是 Java 的一个重要里程碑：非阻塞 IO 和升级版的 ZGC

看起来 Java 21将对 Node JS 构成强大挑战！ Java 21 中有两项巨大的性能增强，它们解决了 Java 经常受批评的两个领域：线程、阻塞 IO（在某种程度上是合理的批评）以及 GC（相对不公平的批评？）

Java 21 的主要亮点：

1. 项目织物和虚拟线程
2. ZGC（升级版）

1. 虚拟线程

长期以来，我们一直关注非阻塞 IO、异步操作，然后是 Promises 和 Async/Await 用于编排异步操作。因此，我们必须处理回调，执行 Promises.all() 或 CompletableFuture.thenCompose() 等操作来联合多个异步操作并处理结果。

最近，反应式框架已经成为画面中的一部分，用于“组合”任务作为函数管道，然后在线程池或执行器上运行它们。反应式函数式编程比“回调地狱”好得多，因此，我们被迫转向函数式编程模型，以便以优雅的方式进行非阻塞/异步操作。

虚拟线程结束了回调和 Promises。Java 团队成功地用几乎可以直接替换虚拟线程取代了线程。因此，即使您执行旧的 Thread.sleep(5000)，虚拟线程也会分离而不是阻塞。就数量而言，常规笔记本可以拥有 2000 到 5000 个线程，而同一台机器可以拥有 100 万多个虚拟线程。事实上，官方建议是避免池化虚拟线程。建议每个任务在新的虚拟线程上运行。虚拟线程支持所有操作 - 休眠、等待、ThreadLocal、锁等。

虚拟线程允许我们只需要编写常规的迭代和“看似阻塞”的代码，然后让 Java 分离/附加真实线程，以使其变为非阻塞和高性能。但是，我们仍然需要等待像 Apache Tomcat 和 Spring 这样的库/框架实现者从本机线程转移到虚拟线程。一旦框架完成过渡，所有使用这些升级框架的 Java 微服务/ 单体将自动变为非阻塞。

举个例子，我们在应用程序中遇到的某些线程池 - Apache Tomcat NIO 有 25-50 个工作线程。想象一下 NIO 可以有 50,000 个虚拟线程。Apache Camel 监听器通常有 10-20 个线程。想象一下 Camel 可以有 1000-2000 个虚拟线程。当然，虚拟线程没有了线程池 - 因此，它们只有无限制的 1000 多个线程。这基本上彻底解决了 Java 的“线程饥饿”问题。

只需升级到完全利用 Java 21 的框架/库，我们所有的 Java 微服务将仅通过现有代码变为非阻塞。

（注意：某些操作，如同步也将阻塞虚拟线程。但是，如果我们将它们替换为虚拟线程支持的替代方法，如Lock.lock()，那么虚拟线程将能够分离并执行其他任务，直到获得锁。对于这一点，需要一些库作者的代码修改，以及在某些情况下需要在项目代码库中进行一些修改，以获得虚拟线程的好处）。

2. ZGC

ZGC 现在支持具有永久亚毫秒暂停的 Terabyte 大小的 Java 堆。没有重要的注意事项...它可能使用额外 5-10% 的内存或5-10% 的较慢分配速度，但不再有全停顿 GC 暂停和不再有堆大小限制。

这两项性能改进将加强 Java 在编程语言中的地位。它可能会阻止 Node JS 的崛起，某种程度上也会使反应式编程受挫。反应式/函数式编程可能仍然对于代码可读性和管理高度事件驱动的应用程序是有好处的，但我们不再需要反应式编程来在 Java 中进行非阻塞 IO。