本文解释为啥会有响应式编程,为什么它在开发者中不太受欢迎,以及引入 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 中的预览功能) 类的组合。
参考:
标签:JDK21,Java,变天,阻塞,响应,虚拟,线程,IO From: https://www.cnblogs.com/JavaEdge/p/17881924.html本文由博客一文多发平台 OpenWrite 发布!