让我们了解一下虚拟线程是如何为开发人员和整个Java生态系统带来主要好处的，以及ZGC是如何改进Java已经强大的GC功能

Java 21中有两个巨大的性能增强，它们解决了Java经常受到批评的两个地方：线程和阻塞IO和GC

Java 21主要亮点：

Project Loom和虚拟线程ZGC升级虚拟线程

很长一段时间以来，我们一直在使用非阻塞IO、异步操作，然后是Promises和async/Await，以协调异步操作。因此，我们必须处理回调，并采取以下措施Promises.all（）或CompletableFuture.thenCompose（）加入几个异步操作并处理结果。

在Reactive框架中将任务“compose”为功能管道，然后在线程池或执行器上运行它们。反应型函数式编程比“回调函数”要好得多，因此，我们被迫转向函数编程模型，以便以优雅的方式实现非阻塞/异步。

虚拟线程以callback和promise来结束，Java开发人员成功地提供了几乎全方位置换对于具有廉价的虚拟线程所以，即使你做旧的thread.sleep(5000)虚拟线程将分离而不是阻塞。就数量而言，一台普通笔记本电脑可以执行2000到5000个线程，而同一台机器可以执行100多万个虚拟线程。事实上，官方建议是避免虚拟线程池。建议在新的虚拟线程上运行每个任务。虚拟线程支持一切—sleep、wait、Threadlocal、lock等。

虚拟线程允许我们只需编写常规的旧迭代和“看似阻塞的”代码，并让Java分离/附加真实的线程，使其成为非阻塞和高性能的。然而，我们仍然需要等待库/框架实现者，如 apache Tomcat和Spring将所有内容从本机线程转移到虚拟线程。一旦框架完成转换，所有Java 微服务

使用这些升级的框架将自动成为非阻塞的。

以我们在应用程序中遇到的一些线程池为例，Apache Tomcat NIO有25-50个工作线程。想象一下，NIO可以拥有50000个虚拟线程。Apache Camel侦听器通常有10-20个线程。想象一下Camel可以有1000-2000个虚拟线程。当然，没有更多带有虚拟线程的线程池，因此，它们将只有无限的1000个线程。这几乎完全停止了Java中的“线程饥饿”。

只要升级到充分利用Java 21的框架/库，我们所有的Java微服务都将变得不受阻塞，只需使用现有代码即可。

（注意：一些操作如synchronized也会阻止虚拟线程。然而，如果我们用虚拟线程支持的替代方案来替换它们，比如lock.lock()然后虚拟线程将能够分离并执行其他任务，直到获得锁为止。为此，需要库作者进行一些代码，在某些情况下还需要在项目代码库中进行一些更改，以获得虚拟线程的好处）。

ZGC

ZGC现在支持具有永久亚毫秒暂停的Terabyte大小的Java堆。没有重要的警告。。。它可能会多使用5-10%的内存或5-10%的分配速度，但不会有更多的stop-the-world GC暂停，也不会有更多堆大小限制。

这两项性能改进将共同加强Java在编程语言中的地位。这可能会暂停Node JS的主导地位，在某种程度上也可能会暂停Reactive编程。反应式/函数式编程对于代码可读性和管理大量事件驱动的应用程序可能仍然很好，但我们没有需要在Java中进行无阻塞IO的反应式编程。