欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos
前文链接
本篇概览
- 本篇是《支持JDK19虚拟线程的web框架》系列的第四篇，主要内容是阅读quarkus源码，开阔眼界，了解框架级别的软件是如何使用虚拟线程的，另外再感受一下整体架构设计的重要性，只有良好的设计才能保证新增能力对现有框架不会造成太大影响
- 另外请放心，虽然quarkus源码复杂，但本文会做到十分克制，不会在虚拟线程之外的地方展开阅读和分析，以保证整篇文章都在聚焦虚拟线程，
- 本文主要由下图的内容构成，红色区域表示本篇核心：一个特别的Excutor对象，咱们只要搞清楚这个对象是如何创建的，以及如何使用，就弄明白了quarkus框架是如何支持虚拟线程的，另外之前咱们用过的@RunOnVirtualThread注解，在解释Executor对象是从哪来的这个问题时也是决定性的，需要追踪它的具体作用：
- 根据上面的规划，本篇将分为以下三部分展开叙述：
- 首先是最具体形象的：前面的代码中，如果要开启虚拟线程就用@RunOnVirtualThread注解去修饰方法，那么咱们首先就要弄明白这个@RunOnVirtualThread注解在代码运行的时候，起到了什么作用？
- 其次是本篇的核心：一个Executor对象的前世今生，今天的文章都会围绕它展开，它是虚拟线程的灵魂，所以本文的第二部分就先弄明白这个重要的Executor是怎么诞生的
- 最后，也就是最重要的：Executor对象是怎么工作的
- 接下来直奔主题吧，一头扎入quarkus源码的汪洋，畅游其中
关于quarkus源码
- 本文中阅读的quarkus源码版本是2.13.3.Final，下载地址：https://codeload.github.com/quarkusio/quarkus/zip/refs/tags/2.13.3.Final
参数isDefaultBlocking，后面多处用到
-
看源码的第一步，咱们先弄明白一个重要参数：isDefaultBlocking，因为后面的源码阅读有好几处都会用到
-
关于isDefaultBlocking，其来源是接口RequestContextFactory，如下图，接口的isDefaultBlocking方法，默认返回是false
- 实际运行中，该接口的实现类是ResteasyReactiveRecorder#createDeployment中创建的匿名类，其代码如下，未实现isDefaultBlocking方法，因此依旧是接口定义中的默认方法生效，返回值就是false
- 记住isDefaultBlocking等于false，接下来回到正题：咱们给web服务类添加的@RunOnVirtualThread注解，到底去了哪里？
@RunOnVirtualThread注解去哪了？
- quarkus应用启动的时候，方法ResteasyReactiveProcessor#setupEndpoints会执行，主要是执行每个endpoint（web服务的可访问地址）的初始化操作，里面会调用EndpointIndexer#createEndpoints方法
- EndpointIndexer#createEndpoints方法中，会为每个web接口方法创建ResourceMethod对象，里面是此web接口方法的配置信息，注意下面箭头所指位置，ResourceMethod对象的成员变量runOnVirtualThread的取值，来自同名的临时变量
- 从下图可见，那个临时变量runOnVirtualThread其实来自方法isRunOnVirtualThread
- 打开EndpointIndexer#isRunOnVirtualThread方法，如下图，如果某个类的某个方法被添加了@RunOnVirtualThread注解，那么下面的getInheritableAnnotation方法返回的就是从此方法中取得的注解对象
- 至于上图中的getInheritableAnnotation方法，我觉得很有必要看一眼，就一眼...，如下图，可见，@RunOnVirtualThread注解不论是写在方法上还是类上都有效
- 至此，可以小结了：咱们开发web服务的过程中，为web服务类添加的@RunOnVirtualThread，都存入了ResourceMethod对象中
- 上面这个结论很重要，后面会用到
- 现在已经顺利弄明白了第一个问题：@RunOnVirtualThread注解去哪了？继续下一个：那个特别的Executor对象是怎么诞生的？
关于Executor
- 本篇最重要的内容就是一个特别的Executor对象，现在就来聚焦它，先看它的创建过程
- quarkus应用启动的时候，方法ResteasyReactiveProcessor#setupDeployment会执行，主要是完成应用启动是的一些初始化操作，里面代码很多，下图箭头所指是本篇最关心的，里面会提取bean的注解做对应的处理
- 现在，重点来了！！！
- 上图红色箭头的代码在ResteasyReactiveRecorder.java中，来看这个createDeployment方法，如下图，第一个箭头处，出现了一个静态变量，名为VIRTUAL_EXECUTOR_SUPPLIER，它先被传给了RuntimeDeploymentManager对象，然后在箭头2位置，RuntimeDeploymentManager对象的deploy中，就会用到这个VIRTUAL_EXECUTOR_SUPPLIER
- 接下来兵分两路，先看上图箭头1中的VIRTUAL_EXECUTOR_SUPPLIER是什么，再看箭头2的deploy中如何使用VIRTUAL_EXECUTOR_SUPPLIER
首先，VIRTUAL_EXECUTOR_SUPPLIER是什么
- 在看之前，先回顾一下JDK官方指导是如何使用虚拟线程的，如下图，一共两步：先调用Executors.newVirtualThreadPerTaskExecutor()创建一个Executor实例（没错，就是咱们平时写多线程代码时的那个Executor），再执行executor.submit方法，这样就创建了虚拟线程，并在虚拟线程中执行业务逻辑：
- 现在去看创建VIRTUAL_EXECUTOR_SUPPLIER的代码就会特别清晰了，如下图，前面在JDK官方指导看到的Executors.newVirtualThreadPerTaskExecutor()，在quarkus这里被改为用反射实现，这样可以避免JDK19以下的环境中出现编译问题，箭头3位置的代码也很重要，如果当前环境不支持虚拟线程，就会返回一个可用的executor，确保业务能执行下去