支持JDK19虚拟线程的web框架,之四:看源码,了解quarkus如何支持虚拟线程

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

本篇概览

  • 本篇是《支持JDK19虚拟线程的web框架》系列的第四篇,主要内容是阅读quarkus源码,开阔眼界,了解框架级别的软件是如何使用虚拟线程的,另外再感受一下整体架构设计的重要性,只有良好的设计才能保证新增能力对现有框架不会造成太大影响
  • 另外请放心,虽然quarkus源码复杂,但本文会做到十分克制,不会在虚拟线程之外的地方展开阅读和分析,以保证整篇文章都在聚焦虚拟线程,
  • 本文主要由下图的内容构成,红色区域表示本篇核心:一个特别的Excutor对象,咱们只要搞清楚这个对象是如何创建的,以及如何使用,就弄明白了quarkus框架是如何支持虚拟线程的,另外之前咱们用过的@RunOnVirtualThread注解,在解释Executor对象是从哪来的这个问题时也是决定性的,需要追踪它的具体作用:
  • 根据上面的规划,本篇将分为以下三部分展开叙述:
  1. 首先是最具体形象的:前面的代码中,如果要开启虚拟线程就用@RunOnVirtualThread注解去修饰方法,那么咱们首先就要弄明白这个@RunOnVirtualThread注解在代码运行的时候,起到了什么作用?
  2. 其次是本篇的核心:一个Executor对象的前世今生,今天的文章都会围绕它展开,它是虚拟线程的灵魂,所以本文的第二部分就先弄明白这个重要的Executor是怎么诞生的
  3. 最后,也就是最重要的:Executor对象是怎么工作的
  • 接下来直奔主题吧,一头扎入quarkus源码的汪洋,畅游其中

关于quarkus源码

参数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,确保业务能执行下去

  • 对于上图箭头3位置的做法,个人并不认同:我使用虚拟线程,就是想一口气创建成千上万线程,再肆无忌惮的使用,遇到不支持虚拟线程的场景,直接抛异常让我知道这条路走不通,逼我再去想办法解决,这样不好么?而箭头3位置显然返回的是传统线程,这么一来,岂不是成了创建成千上万的传统线程了?这谁扛得住?关键是,在开发阶段,因为条件所限,可能只构造了少量线程来验证基本功能,如果就这样发布到生产环境,就有可能创建大量传统线程,导致CPU的内核态使用率上涨,影响系统整体性能
  • 至此,咱们算是搞清楚这个executor是啥了:用Executors.newVirtualThreadPerTaskExecutor()创建的Executor实例,虽然是用反射,但本质上得到的结果和JDK方法的推荐做法一致

其次,RuntimeDeploymentManager#deploy方法里是什么?

  • 刚才说好的兵分两路,先看VIRTUAL_EXECUTOR_SUPPLIER是什么,再看RuntimeDeploymentManager#deploy()方法

  • 该方法内容很多,咱们还是只看虚拟线程有关的,如下图,VIRTUAL_EXECUTOR_SUPPLIER成了runtimeResourceDeployment的成员变量,然后针对每个bean的每个方法,都要执行一次箭头4指向的buildResourceMethod方法,此方法是关键,接下来重点看

  • 展开上图箭头4的方法,原来如此,注意箭头指向的method.isRunOnVirtualThread(),这个在前面已经分析过了,咱们用@isRunOnVirtualThread修饰过的web接口,在这里返回的值就是true,就会执行箭头2所指的代码,为此web接口添加一个handler,从名字上看,这个blockingHandlerVirtualThread和之前咱们一直关注的VIRTUAL_EXECUTOR_SUPPLIER应该有不小的关系
  • 看RuntimeResourceDeployment的构造方法,果然VIRTUAL_EXECUTOR_SUPPLIER是blockingHandlerVirtualThread构造方法的入参

  • 至此就要先打住了,不要急着看BlockingHandler的代码,那里面的东西是在处理web请求时才会执行,到目前为止咱们的重点还只是分析Executors.newVirtualThreadPerTaskExecutor()方法创建的executor去了哪里,现在就小结一下吧

  • 一图胜千言,本篇最核心的Executor对象的诞生过程,由一个主线逻辑和两个支线逻辑组成,如下图,红色代表主线任务,它负责遍历所有web接口对应的方法,发现该方法需要用虚拟线程执行时,就为此方法绑定一个BlockingHandler对象,这个handler的成员变量中,就有直线逻辑用JDK19特定的方法创建出来的虚拟线程特有的executor对象,至于这个handler对象怎么用?就是本篇的另一半重要内容了:执行虚拟线程

  • 至此,本篇的第二个重要问题:这个特别的Executor对象是哪来的,这个问题已经弄明白了(好像一句话就能说清楚:放入了和web接口方法关联的handler中),接下来是最后一个问题:这个特别的Executor对象应该怎么用?

这个特别的Executor对象应该怎么用?

  • 由于虚拟线程是在处理web响应的时候被用到的,所以分析这个特别的Executor对象时,不可避免的进入了quarkus处理web响应的复杂逻辑中,之所以说复杂,因为这里面最底层涉及到netty,再往上又涉及到vertx库,如果咱们从头去看会严重偏离主题,所以接下来分析web响应的代码时,我这边就尽量简化了
  • 代码分析中RestInitialHandler#beginProcessing方法开始吧,对于反应式web服务,每次请求都会执行此方法,如下图,红色箭头指向的ResteasyReactiveRequestContext对象需要重点关注,这里面放置了本次web请求的相关信息,接下来就会执行此对象的run方法

  • 打开run方法,豁然开朗,前面咱们看到为web接口方法绑定handler,这里会取出handler依次执行
  • 上图的方法是在中实现的,打开代码后吓了我一跳,估计quarkus的人也怕被喷,在注释中看到了他们满满的求生欲:代码写成这样是为了性能考虑,这样写就是单态调用,取代了简化写法中的多态调用,会有更好的性能表现(不敢说学到了新技术,只能说开阔了眼界)

  • 上面的代码其实就是调用hanler的handle方法,所以,是时候去看那个BlockingHandler的handler方法了

  • 刚打开代码就大呼一声痛快!如下图,handler将虚拟线程的executor和web请求的上下文对象requestContext串起来了,接下来该去箭头2所指的resume中一探究竟,我这里大胆的猜一下,resume方法中要做的事情应该和Runnable有关,理由很简单:Runnable和Executor不就是配合着用的嘛

  • 上图箭头2的代码在AbstractResteasyReactiveContext.java中,先看这个AbstractResteasyReactiveContext类,果然实现了Runnable

  • 接下来该看AbstractResteasyReactiveContext#resume方法了,看之前我猜应该是executor.execute(this),因为我只会这么写...,打开代码一看就乐了,原来我只会这么写就够了,因为他们也是这么写的,注意箭头2,本文的核心也就是这段代码了
  • 写到这里,关于executor的使用也全部分析完了,用一个简化图小结吧
  • 至此,quarkus支持虚拟线程的相关代码已经阅读完毕,这里再做个小结:
  1. 咱们在web接口类上添加的@RunOnVirtualThread注解,会存入每个web接口方法对应的ResourceMethod对象中
  2. 应用在初始化的时候,检查web接口方法对应的ResourceMethod对象,如果需要在虚拟线程中响应,就给这个web接口绑定一个BlockingHandler对象,此对象有个成员变量,是个executor,是通过Executors.newVirtualThreadPerTaskExecutor()方法创建的
  3. web请求到达时,web接口方法的handler对象会被拿来执行其handler方法,BlockingHandler也是其中之一
  4. BlockingHandler的handler方法中,会使用executor.execute方法来执行web响应逻辑,此方法会创建创建虚拟线程,在虚拟线程中完成web响应
  • 相比前面三篇的动手实战,本篇主要在阅读quarkus源码,略显枯燥,尽管已尽量用图来辅助理解,但是读源码就是这样,不但捷径很少,岔路还特别多,好在咱们一路咬牙坚持下来了,收获也不会少

后面更精彩

  • 下一篇文章就是整个系列的终篇了,相比本文,终篇会简单很多,大家一起在轻松的氛围中畅谈线程技术的一个重要成员:ThreadLocal,看它在虚拟线程时代如何兴风作浪

欢迎关注博客园:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

热门相关:亿万盛宠只为你   慕少,你老婆又重生了   上将大叔,狼来了!   我是仙凡   重生之嫡女祸妃