Java 虚拟线程：案例研究

一. 关键要点

• 虚拟线程是 Java 并发编程的一个重要进步，但在运行典型的云原生 Java 工作负载方面，它们并不比 Open Liberty 现有的自主线程池具有明显的优势。
• 对于 CPU 密集型工作负载，由于目前尚不清楚的原因，虚拟线程的吞吐量低于 Open Liberty 的线程池。
• 由于采用了每个请求一个线程的模型，虚拟线程从空闲到最大吞吐量的加速时间比 Open Liberty 的线程池更快。
• Open Liberty 部署中的内存占用量会因应用程序设计、工作负载级别和垃圾收集行为等因素而有很大差异，因此虚拟线程占用量的减少可能不会导致内存使用量的整体减少。
• 虚拟线程在某些用例中表现出一些意外的性能问题，Java 开发人员应该注意这一点。

JDK 21 的发布带来了一个广为人知的新功能——Java 虚拟线程。该功能标志着 Java 开发人员在更好地处理应用程序中的并行性方面取得了重大飞跃。Java 虚拟线程的一些目标包括：

• 轻量级、可扩展且用户友好的并发模型
• 高效利用系统资源
• “大大减少编写、维护和观察高吞吐量并发应用程序的工作量”（JEP425）

虚拟线程引起了 Java 开发者社区的极大兴趣，其中包括应用程序框架，例如Open Liberty，这是一个开源、模块化、云原生的 Java 应用程序运行时。评估了这项新的 Java 功能是否可以为我们的用户带来好处，甚至可能取代 Liberty 应用程序运行时本身使用的当前线程池逻辑。至少，我们希望更好地了解虚拟线程技术及其性能，以便我们能够为 Liberty 用户提供明智的指导。

本文报告了我们的发现。其中包括：

• Java 虚拟线程实现的概述。
• 当前 Liberty 线程池技术的概述。
• 我们对一些绩效指标进行了评估，包括一些意外的观察结果。
• 我们的研究结果的摘要。

二. Java 虚拟线程

虚拟线程首次在 JDK 19 中引入，在 JDK 20 中得到增强，并在 JDK 21 中最终确定（如JDK 增强提案 (JEP) 444中所述）。

过去，Java 开发人员使用“每个请求一个线程”模型实现应用程序，其中每个请求在其生命周期内由专用线程处理。这些线程（称为平台线程）作为操作系统线程（OS 线程）的包装器实现。但是，OS 线程占用大量系统内存并由 OS 层调度，随着部署的线程越来越多，这可能会导致扩展问题。

虚拟线程的主要动机之一是保持线程请求模型的简单性，同时避免专用操作系统线程的高成本。虚拟线程通过最初将每个线程创建为 Java 堆上的轻量级对象，并仅在需要时使用操作系统线程，最大限度地减少了此问题。这种操作系统线程的“共享”可以更好地利用系统资源。从理论上讲，这是虚拟线程的一个优势：开发人员现在可以在单个 JVM 中有效地使用“数百万个线程”。

下图显示了 Java 虚拟线程和 OS 线程之间的多对一关系，然后这些线程被调度在 CPU 级别运行。

三. Open Liberty 的自主线程池

Open Liberty 的共享线程池方法还最大限度地降低了专用 OS 线程的高成本。Liberty 使用共享线程（称为“Liberty 线程池”）来执行应用程序业务逻辑功能，并为 I/O 功能分配单独的线程。此外，Liberty 线程池具有自适应性，并且可以自动调整大小（如本文所述）。对于大多数用例，无需进行额外调整，但可以选择配置最小和最大池大小。

与 Web 服务器（例如使用虚拟线程实现的 Helidon Web 服务器）不同，Liberty 之类的应用程序运行时不仅仅是建立 I/O 连接，然后长时间处于空闲状态。在 Liberty 上运行的应用程序通常会执行大量业务逻辑，这需要 CPU 资源。Liberty 部署通常不会使用数千或数百万个线程，因为 CPU 资源被几百个线程（或更少）完全消耗，尤其是在仅分配了几个甚至一小部分 CPU 的容器或 pod 中。

四. 性能测试

我们的评估主要侧重于 Liberty 客户常用的用例和配置。我们使用现有的基准测试应用程序来比较 Liberty 的线程池和虚拟线程的相对性能。这些基准测试应用程序使用 RES