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

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

1 同步阻塞设计

1.1 同步阻塞设计的线程图

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

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

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

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

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

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

1.2 评估

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

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

2 异步阻塞设计

2.1 异步阻塞设计线程图

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

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

• 一个用于处理从数据库获取数据
• 另一个用于从 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 管道（或任何其他管道），并在尽可能短的时间内将其释放回线程池（因为无需再保持活动状态以向用户发送数据）。

此时，用户请求线程创建一个运行 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 完全响应式样式设计线程图

每个获取数据的 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可继续使用与以前相同的命令式开发风格，同时获得使用响应式管道时获得的可扩展性优势（但没有复杂性）。

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

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

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

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

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

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

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

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

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

7 总结

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

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

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

参考：

• 编程严选网

  本文由博客一文多发平台 OpenWrite 发布！