响应式编程又变天了？看JDK21虚拟线程如何颠覆！

我会带着你远行 2024-02-05 12:58 61阅读 0赞

![6d9556379dd54100bcaa1c9afd03ba14.png][]

本文解释为啥会有响应式编程，为什么它在开发者中不太受欢迎，以及引入 Java 虚拟线程后它可能最终会消失。

命令式风格编程一直深受开发者喜爱，如 if-then-else、while 循环、函数和代码块等结构使代码易理解、调试，异常易追踪。然而，像所有好的东西一样，通常也有问题。这种编程风格导致线程被阻塞时间远超过必要时间。

### 1 同步阻塞设计 ###

#### 1.1 同步阻塞设计的线程图 ####

为了便于你理解，让我们看一个典型的企业用例请求：

*  从DB获取数据
 *  从 Web 服务获取数据
 *  合并结果并将最终合并的结果发送回用户

在像 Tomcat 这样的应用服务器中，一个平台线程将专用于用户请求，该线程将继续调用从数据库获取数据的代码（调用 *FetchDataFromDB*），然后调用从 Web 服务获取数据的代码（调用 *FetchDataFromService*），然后继续合并并将数据发送给用户（调用 *SendDataToUser*）。

如下图，将执行线程从上到下表示为一个垂直箭头：

*  绿色是执行的 CPU 部分
 *  红色是线程等待数据的时间

大多企业应用都是 IO 绑定的，因此线程在大多时间内实际是浪费资源。

![864a5626be2744f4946bfa99caa67980.png][]

#### 1.2 评估 ####

Java 中，平台线程是昂贵资源，因为默认，每个平台线程消耗 **1MB** 栈内存。即 JVM 中运行的平台线程数量有上限。因此，若一个平台线程专用于用户请求，对高并发用户的应用程序，就带来问题。传统解决方案是创建一个具有最大线程数的线程池，并根据需要水平或垂直扩展应用程序：

*  垂直扩展意味着向容器或 VM 添加更多资源
 *  水平扩展则意味着添加应用程序的更多实例

### 2 异步阻塞设计 ###

#### 2.1 异步阻塞设计线程图 ####

为了提高性能，可用异步模型，并行运行一些串行任务。如若假设数据库和 Web 服务的获取任务可以并行运行，那么它们可以在各自的平台线程中执行。

![image-20231207103631608][]

用户请求线程启动两个线程：

*  一个用于处理从数据库获取数据
 *  另一个用于从 Web 服务获取数据
 *  然后，它将阻塞以获取两者结果，然后继续合并并将数据发送给用户

在 Java 可通过向 Executor Service 提交 Callable 或 Runnable 任务并使用 Java Futures 来实现。

#### 2.2 评估 ####

这将提高性能，因为两个数据获取是并行执行的。但是，即使在大多数时间内可能会有性能提升，但是在短时间内，平台线程的数量现在从 1 增加到 3。从可扩展性看，在那段时间内情况更坏。

### 3 响应式样式设计 ###

响应式编程设计就是为解决这问题。

#### 3.1 部分响应式设计线程图 ####

在于昂贵的平台线程在阻塞操作期间浪费大部分时间。随 **Servlet 3.0** 和 **3.1** 引入，Servlet 线程在发送 HTTP 数据回用户时无需保持活动状态，这为更巧妙编程打开解决线程阻塞的大门。Java 8 CompletableFuture类可在其中创建响应式管道。这种开发风格思想是为该用例指定一个执行管道，而非执行用例本身。

用户请求线程只需指定用例的 CompletableFuture 管道（或任何其他管道），并在尽可能短的时间内将其释放回线程池（因为无需再保持活动状态以向用户发送数据）。

![b6f5c3646ad44b79ba035cca1ce8318c.png][]

此时，用户请求线程创建一个运行 3 个活动的管道：

*  先并行运行 FetchDataFromService、FetchDataFromDB
 *  再运行 Send2User

但创建此管道后，用户请求线程将被简单释放回线程池。大大减轻 JVM 负担，因为现在它有一个较少的线程要处理。一旦数据提取线程完成其执行，数据将被发送给用户。

#### 评估 ####

但这只是部分解决问题，因为从 Web 服务、DB获取数据的实际活动仍是在它们各自的平台线程中阻塞。这带来问题：SE须确保他从管道中生成的任务不是阻塞的。这很难做到，因为它是手动完成的，并且肯定是错误的，因为在编译时或运行时它不会被标记为警告或错误。

### 4 完全响应式样式设计 ###

如何才能表现更好？达到更高标准 OKR 呢？为使该设计完全响应式，须以非阻塞方式获取DB、Web 服务的数据。

作为 **JDK 7** 的一部分，**NIO（New IO）** 为非阻塞 IO 打开大门。Java 所有基于 IO 类和方法都有非阻塞版本了。如socket读/写、文件读/写、锁 API 等。须使用这些类/方法的非阻塞版本或支持 NIO 的库来进行数据的获取。

#### 4.1 完全响应式样式设计线程图 ####

![82fad83756994f49b9e0da15404cdbe1.png][]

每个获取数据的 Fetch Data 中，发出请求的线程和获取数据的线程不同，如：

*  从 Web 服务检索数据的 HTTP GET 请求将在一个线程上运行
 *  而最终处理检索到的数据的线程将在另一个线程上运行

这就是完全响应式，它解决了关键问题：IO 操作期间不阻塞。在这里使用平台线程的唯一时间是在 CPU 操作期间，而不是在 IO 操作期间。在平台线程的执行部分已看不到任何红色部分。

这种开发风格能实现应用程序高可扩展性。然而，解决方案过复杂。创建响应式管道、调试它们及想象它们的执行很困难。所以很正常，这种开发风格没有流行开来，只有顶尖的开发者才对此爱不释手。**Spring Boot** 专门用于响应式风格编程的完整开发技术栈即 **Spring WebFlux**，它使用 Project Reactor 库提供了对DB、Web 服务等的非阻塞行为。

### 5 虚拟线程 ###

还有响应式设计的其他替代方案吗？当然了！如今 **Java 21** 的发布，Oracle 推出备受期待的 **Virtual Threads** 功能。

平台线程问题是在阻塞操作期间，实际变得无用。平台线程基本是os线程的简易包装，毕竟os线程是昂贵的。

而虚拟线程是 JVM 中 Thread 类的实现，它是轻量级的。最终归结为以下几点 — 当使用虚拟线程进行代码执行时，它将在 CPU 操作期间使用平台线程（称为载体线程），并且在遇到 IO 操作时将载体线程释放。

#### JVM如何知道何时遇到 IO 操作？ ####

虚拟线程中运行时，JVM 将自动切换到使用 IO 操作的非阻塞版本。这种更改已在大多核心 Java 类库中为大多数 IO 操作进行了痛苦修改。当代码遇到 IO 操作，载体线程将被释放，并且在该 IO 的数据可用时，虚拟线程将被重新安排在另一个载体线程上处理数据。即在虚拟线程中阻塞不是问题，因为底层的载体线程被释放了。

SE现在可选择使用虚拟线程进行用户请求。即SE可继续使用与以前相同的命令式开发风格，同时获得使用响应式管道时获得的可扩展性优势（但没有复杂性）。

#### 具有虚拟线程的同步阻塞线程图 ####

这种方式在同步阻塞设计中的情况（注意，阻塞不是一个问题）。

![9603271cf9e6470998d6794921276b74.png][]

用户请求线程是虚拟线程（蓝色垂直箭头）。线程上的红色不再是问题，因为阻塞操作期间，底层的载体线程将被释放，从而实现与使用响应式框架相同的可扩展性优势。

### 6 虚拟线程和异步阻塞设计 ###

#### 6.1 异步阻塞设计中的虚拟线程 ####

阻塞在此也不再是问题。前面提到可用 Java Futures 实现，我们确实有这样做的选择。但Java 21引入 **StructuredTaskScope** 和 **Subtask** ，以处理结构化异步行为。

![0ca9418fde3b4633820c7b7577962d48.png][]

**虚拟线程** 和 **StructuredTaskScope** 的组合将非常强大。虚拟线程使阻塞不再是一个问题，而 **StructuredTaskScope** 将为我们提供更高级别的类，以直观的方式处理异步编程。很难看到为什么还需要 Completable Futures。

#### 虚拟线程 V.S 响应式框架 ####

*  可继续使用命令式风格开发
 *  无需创建复杂的响应式管道
 *  无需在代码中直接使用非阻塞 IO
 *  更易编码、调试和理解

### 7 总结 ###

随着 **Java 21** 中 **虚拟线程** 引入，虚拟线程在阻塞状态下不再是问题。开发人员：

*  无需创建复杂的响应式风格管道
 *  且无需在代码中直接使用非阻塞 IO

即可创建高度可扩展的应用程序。替代方案是使用 **Java 21** 中引入的 **虚拟线程** 与 Java Futures 或 **Structured Concurrency（Java 21 中的预览功能）** 类的组合。

参考：

*  编程严选网
    
    > 本文由博客一文多发平台 [OpenWrite][] 发布！

[6d9556379dd54100bcaa1c9afd03ba14.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/8a4bdfbbbcb3404eb9fe98850e02b920.png
[864a5626be2744f4946bfa99caa67980.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/77c4b346df874c138384cf62b2551bb5.png
[image-20231207103631608]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/4bd46884d323474c887a7d5f784735c6.png
[b6f5c3646ad44b79ba035cca1ce8318c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/04d1b67168f94c4b87029fe717b905d3.png
[82fad83756994f49b9e0da15404cdbe1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/242be42ea98e4c70b6d0c5a1efde0a85.png
[9603271cf9e6470998d6794921276b74.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/060ecf1eab524277bb8c4f8f310e72a0.png
[0ca9418fde3b4633820c7b7577962d48.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/406e5ac8a7634cef8d4553ff1465d24b.png
[OpenWrite]: https://openwrite.cn?from=article_bottom