你好呀,我是歪歪。

这周我在 Spring 的 github 上闲逛的时候,一个 issues 引起了我的兴趣。

这篇文章,是我顺着这个 issues 往下写,始于它,但是不止于它:

https://github.com/spring-projects/spring-framework/pull/27818

这个 issues 标题翻译过来,就是说希望 @Async 这个注解能够支持占位符或 SpEL 表达式。

而我关注到这个 issues 的原因,完全是因为我之前写过 @Async 相关的文章,看着眼熟,就随手点进来看了一下。

在这个问题里面,提到了一个编号为 27775 的 issues:

https://github.com/spring-projects/spring-framework/issues/27775

这个说的是个啥事儿呢?

估计你看一眼我截图中标注的地方也就看出来了,他想把线程池的名称放到配置文件里面去。而这个需求我觉得并不奇怪,基于 Spring 框架来说,是一个很合理的需求。

搞个 Demo

我还是先给你搞个 Demo,验收一下它想要干啥。

首先注入了一个名称为 why 的线程池。

然后有一个被 @Async 注解修饰的方法,而这个注解指定了一个值为 why 的 value,表明要使用名称为 why 的这个线程池:

接着我们还需要一个 Controller,触发一下:

最后在启动类上加上 @EnableAsync 注解,把项目启动起来。

调用下面的链接,发起调用:

http://127.0.0.1:8085/insertUser?age=18

输出结果如下:

说明配置生效了。

然后,提出 issues 的这个哥们,他想要这么一个功能:

也就是让 @Async 注解和配置文件进行联动。

目前 Spring 的版本是不支持这个东西的,比如我把项目启动起来之触发一次:

直接抛出了 NoSuchBeanDefinitionException,说明 @Async 的 value 注解并没有解析表达式的功能。

支持一波

好的,现在需求就很明确了:目前不支持,有人在社区提出该需求,想要 Spring 支持该功能。

然后这个叫 sbrannen 的哥们出来了:

他说了两句话:

  • 1.如果提供的 BeanFactory 是 ConfigurableBeanFactory,我们似乎可以通过修改 org.springframework.aop.interceptor.AsyncExecutionAspectSupport.findQualifiedExecutor(BeanFactory,String) 的代码,使用 EmbeddedValueResolver 来支持。
  • 可以看一下 org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.setBeanFactory(BeanFactory),这是一个对应的例子。

第一句话中,他提到的 findQualifiedExecutor 方法,也就是需要修改的地方的代码,在我的 5.3.16 版本中是这样的:

你先记住入参中有一个 beanFactory 就行了。

而第二句话中提到的 setBeanFactory 方法,是这样的:

他说的 “for an example” 就是我框起来的部分。

这里面关键的地方有两个:

  • ConfigurableBeanFactory
  • EmbeddedValueResolver

首先 ConfigurableBeanFactory ,在 Spring 里面是一个非常重要的类,但是不是本文重点,一句话带过:你可以把它理解为是一个巨大的、功能齐全的工厂接口。

重点是 EmbeddedValueResolver 这个东西:

从注解上可以知道这个类是用来解析占位符和表达式。相当于是 Spring 给你封装好的一个工具类吧。

EmbeddedValueResolver 里面就这一个方法:

而这个方法里面调用了一个 resolveEmbeddedValue 方法:

org.springframework.beans.factory.support.AbstractBeanFactory#resolveEmbeddedValue

这个方法就是 Spring 里面解析表达式的核心代码。

我给你演示一下。

首先我们加一点代码:

这个代码不需要解释吧,已经很清晰了。

我只需要在我们前面分析的代码这里打上断点,然后把程序跑起来:

是不是很清晰了。

入參是 ${user.age} 表达式,出参是配置文件中对应的 18。

关于如何解析的所有秘密都藏在这一行代码里面:

你以为我要给你详细讲解吗?

不可能的,指个路而已,自己看去吧。

现在我要开始拐弯了,拐回到这个老哥的回复上:

现在我先带你捋一捋啊。

首先,有个老铁说:你这个 Spring 的 @Async 注解能不能支持表达式呀,比如这样式儿的 @Async("${thread-pool.name}")

然后官方出来回复说:没问题啊,我们可以修改 findQualifiedExecutor 方法,在里面使用 EmbeddedValueResolver 这个工具类来支持。比如就像是下面这个类中的 setBeanFactory 方法一样:

接着我带你去看了一下这个方法,然后知道了 EmbeddedValueResolver 的用法。

好的,那么现在问题来了:在 findQualifiedExecutor 方法中,我们怎么使用呢?

兜兜转转一大圈,现在就回到最开始的那个 issues 里面:

这个老哥说他基于 sbrannen,也就是官方人员的提示.提交了这次修改。

怎么修改的呢?

看他的 Files changed:

修改了三个文件,其中一个测试类。

剩下两个,一个是 @Async 注解:

这里面只是修改了 Javadoc,表示这个注解支持表达式的方式进行配置。

另外一个是 AsyncExecutionAspectSupport 这个类:

在 findQualifiedExecutor 方法里面加了五行代码,就完成了这个功能。

最后,官方在 review 代码的时候,又删除一行代码:

也就是 4 行代码,其实应该是 2 行核心代码,就完成了让 @Async 支持表达式的这个需求。

而且官方是先给你说了解决方案是什么,只要你稍微你跟进一下,发动你的小脑壳思考一下,我想你写出这 4 行代码也不是什么困难的事情。

这就是给 Spring 贡献源码了,而且是一个比较有价值的贡献。如果是你抓住了这个机会,你完全可以在简历上写一句:给 Spring 贡献过源码,让 @Async 注解支持表达式的配置方式。

一般来说对 Spring 了解不深入的朋友,看到这句话的时候,只会觉得很牛逼,想着应该是个大佬。

但是实际上,2 行核心代码就搞定了。

所以你说给 Spring 贡献源码这个事儿难吗?

机会总是有的,就看你有没有上心了。

什么,你问我有没有给 Spring 贡献过源码?

我没有,我就是不上心,咋的了。

这是我写这个文章想要表达的第个观点:

给开源项目贡献源码其实不是一件特别困难的事情,不要老想着一次就提交一整个功能上去。一点点改进,都是好的。

调试技巧

前面提到的代码改进, Spring 还没有发布官方的包,但是我想要自己试验一下,怎么办呢?

你当然可以把 Spring 的源码拉下来,然后自己编译一波,最后本地改改源码试一试。

但是这个过程太过复杂了,基本上可以说是一个劝退的流程。

为了这么一个小验证,完全不值当。

所以我教你一个我自己研究出来的“骚”操作。

首先,我本地的 Spring 版本是 5.3.16,对应这部分的源码是这样的:

还是先改造一下程序:

然后把程序跑起来,触发一次调用,就会停在断点的地方:

这个时候我们可以看到 qualifier 还是一个表达式的形式。

接着骚操作就来了。

你点击这个图标,对应的快捷键是 Alt+F8:

这是 ide 提供的 Evaluate Expression 功能,在这个里面是可以写代码的。

比如这样:

它还可以偷梁换柱,我在这里把 qualifier 修改为 “yyds” 字符串:

然后跑过断点,你可以从异常信息中看到,它是真的被修改了:

那么,如果我把这次提交的这 4 行代码,利用 Evaluate Expression 功能执行一下,是不是就算是模拟了对应的修改后的功能了?

我就问你:这个方法“骚”不“骚”。

接下来,我们就实操起来。

把这几行代码,填入到 Evaluate 里面:

if (beanFactory instanceof ConfigurableBeanFactory) {
 EmbeddedValueResolver embeddedValueResolver = new EmbeddedValueResolver((ConfigurableBeanFactory)beanFactory);
 qualifier = embeddedValueResolver.resolveStringValue(qualifier);
}

输入代码片段,记得点击一下这个图标:

点击执行之后是这样的:

然后看输出日志,你可以看到这样一行:

说明我的“偷梁换柱”大法成功了。

这不比你去编译一份 Spring 源代码来的方便的多?

而且这个调试的方法,相当于是你在 debug 的时候还能再额外执行一些代码,所以有的时候真的有时候能起到奇效。

这是我写这篇文章的第二个目的,想要分享给你这个调试方法。

不同之处

细心的读者肯定发现了,官方的代码有点奇怪啊:

首先 instanceof 是 Java 的保留关键字,它的作用是测试它左边的对象是否是它右边的类的实例,返回 boolean 的数据类型。

但是我记得 instanceof 不是这样用的呀?这是个什么骚操作啊?

不慌,先粘出来,放到 ide 里面看看啥情况:

我们常用的写法都是标号为 ① 那样的,当我在我的环境里面写出标号为 ② 的代码的时候,ide 给我了一个提示:

Patterns in 'instanceof' are not supported at language level '8'

大概意思是说 instanceof 的这个用法在 JDK 8 里面是不支持的。

看到这个提示的一瞬间,我突然想起了,这个写法好像是 JDK 某个高级版本之后支持的,很久之前在某个地方瞟到过一眼。

然后我用 “Patterns instanceof” 关键词查了一下,发现果然是 JDK 14 版本之后支持的一个新特性。

https://www.baeldung.com/java-pattern-matching-instanceof

我就直接把文章中的例子拿出来给你说一下。

我们用 instanceof 的时候,基本上都是需要检查对象的类型的场景,不同的类型对应不同的逻辑。

好,我问你,你使用 instanceof,在类型匹配上了之后,你的下一步操作是什么?

是不是对对象进行强制类型转换?

比如这样的:

在上述代码截图中,我们每种情况要通过 instanceof 判断 animal 的具体类型,然后强制类型转换声明为局部变量,接着根据具体的类型执行指定的函数。

这有的写法有很多缺点:

  • 这么写非常单调乏味,需要检测类型然后强制类型转换。
  • 每个 if 都要出现三次类型名。
  • 类型转换和变量声明可读性很差
  • 重复声明类型名意味着很容易出错,可能导致未预料到的运行时错误。
  • 每新增一个animal 类型就要修改这里的函数。

注意我加粗的地方,和原文是一样的,这波强调和细节是拉满了的:

为了解决上面提到的部分缺点,Java 14 提供了可以将参数类型检查和绑定局部变量类型合并到一起的 instanceof 操作。

就像这样式儿的:

首先在 if 代码块对 animal 的类型和 Cat 进行匹配。先看 animal 变量是否为 Cat 类型的实例,如果是,强转为 Cat 类型,并赋值给 cat。

需要注意的是变量名 cat 并不是一个真正存在的变量,只是模式变量的一个声明而已。你可以理解为固定语法。

变量 cat 和 dog 只有当模式匹配表达式的结果为 true 时才生效和赋值。所以如果你一不小心把变量用在别的地方,直接会提醒你编译错误。

所以你对比一下上面两个版本的代码,肯定是 Java 14 版本的代码更简洁,也更易懂。减少了大量的类型转换,而且可读性大大提高。

回到 Spring

你看,本来是看 Spring 的,怎么突然写到了 JDK 的新特性了呢?

那必然是我埋下的伏笔啊。

我给你看一个东西:

https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

官方在去年的 SpringOne 大会上就宣布了:Spring 6.0 和 Spring Boot 3 这两大框架的 JDK 基线版本是 17。

也就是说:我们很有可能在 JDK 8 之后,下一个要拥抱的版本是 JDK 17。

而我,作为一个技术爱好者的角度来说:这是好事,得支持,大力支持。

但是,作为一个写着 CRUD 的 Java 从业者来说:想想升级之后各种兼容性问题就头疼,所以希望这个拥抱不要发生在我短暂的职业生涯中。去让那帮年轻力壮,刚刚入行的小伙子们去折腾吧。

而当我把视角局限在这篇文章的角度,电光火石之间,我又想到了一个给 Spring 贡献源码的“骚”操作。

历史代码中这么多用 instanceof 的地方,我只要在 6.0 分支里面,把这些地方都换成新特性的写法,那岂不是一个更简单的贡献源码的方式?

但是,在提交 issues 之前,一般流程都是要先去查询一下有没有类似的提交。

所以在干这事之前,我还是先冷静的查询了一下。

一查,我都笑了...

我都能想到,肯定其他人也能想到,果然有人已经捷足先登了。

比如这里:

https://github.com/spring-projects/spring-framework/issues?q=instanceof

这次对应提交的代码是这样的:

然后,官方还在里面小小的吐槽了一波:

简单来说就是:老哥,这样的小改进,就还是不要提 issue 了吧。你得整个大的啊,别只改一个类啊。

我觉得也是,你改你改一个模块也行呀,比如这位老哥,改了 Spring-beans 模块下的 8 个文件:

这样才是针对这类改动的正确姿势。

反正我把路指在这里了,你要是有兴趣,可以去看看 Spring 6.0 的代码是不是还有一些没有改的地方,你去试着提交一把。

这个话题又回到我最开始表达的第一个观点了:

给开源项目贡献源码其实不是一件特别困难的事情,不要老想着一次就提交一整个功能上去。一点点改进,都是好的。

提交的东西确实是和 Spring 框架关系不大,但是你至少能体验一下给开源项目做贡献的流程和感觉吧,而且越大的项目,流程约精细,肯定是能学到东西。

而这个过程中学到的东西,绝对比你提交一个 instanceof 改进大的多,所以你还能说这样的提交是没有什么营养的嘛?

比如我去年的一篇文章中,就提到了 Dubbo 在对响应报文进行解码的时候有一个没必要的重复操作,可以删除一行校验相关的代码。

我没有去提对应的 pr,但是我写在了文章中。

有个读者看到后,当天中午就去提交了,官方也很快入库了。

去年年底的时候 Dubbo 社区搞了一个回馈活动,就给他送了一个咖啡杯:

意外惊喜,一行代码,不仅可以学点知识,还可以免费得个咖啡杯,就问香不香。

升华一下

好了,回顾一下这篇文章。

我从 @Async 支持表达式作为引子,引到了 instanceof 的新特性,接着又引到了 Spring 6 会以 JDK 17 作为基线版本。

其实我写这篇文章的时候,脑海中一直在萦绕着一句话:大风起于青萍之末。

instanceof,是青萍之末。

大风就是 JDK 17 作为基线版本。

关于为什么要用 JDK 17 作为基线版本,其实这是风华正茂的 Java 的一次渡劫。渡劫是否成功,关系着我们每一个从业者。

在云原生的“喧哗”之下,走在前面的人已经感受到:大风已经吹起来了。

比如周志明博士在一次名为《云原生时代,Java 的危与机》中说了这样的一段话:

https://icyfenix.cn/tricks/2020/java-crisis/qcon.html

未来一段时间,是 Java 重要的转型窗口期,如果作为下一个 LTS 版的 Java 17,能够成功集 Amber、Portola、Valhalla、Loom 和 Panama 的新能力、新特性于一身,GraalVM 也能给予足够强力支持的话,那 Java 17 LTS 大概率会是一个里程碑式的版本,带领着整个 Java 生态从大规模服务端应用,向新的云原生时代软件系统转型。

可能成为比肩当年从面向嵌入式设备与浏览器 Web Applets 的 Java 1,到确立现代 Java 语言方向(Java SE/EE/ME 和 JavaCard)雏形的 Java 2 转型那样的里程碑。

但是,如果 Java 不能加速自己的发展步伐,那由强大生态所构建的护城河终究会消耗殆尽,被 Golang、Rust 这样的新生语言,以及 C、C++、C#、Python 等老对手蚕食掉很大一部分市场份额,以至被迫从“天下第一”编程语言的宝座中退位。

Java 的未来是继续向前,再攀高峰,还是由盛转衰,锋芒挫缩,你我拭目以待。

而我,还只是看到了青萍之末。

最后,文章首发于公众号[why技术],欢迎关注,第一时间接收最新文章。

舒服,给Spring贡献一波源码。的更多相关文章

  1. Spring AOP高级——源码实现(1)动态代理技术

    在正式进入Spring AOP的源码实现前,我们需要准备一定的基础也就是面向切面编程的核心——动态代理. 动态代理实际上也是一种结构型的设计模式,JDK中已经为我们准备好了这种设计模式,不过这种JDK ...

  2. Spring AOP高级——源码实现(2)Spring AOP中通知器(Advisor)与切面(Aspect)

    本文例子完整源码地址:https://github.com/yu-linfeng/BlogRepositories/tree/master/repositories/Spring%20AOP%E9%A ...

  3. Spring AOP高级——源码实现(3)AopProxy代理对象之JDK动态代理的创建过程

    spring-aop-4.3.7.RELEASE  在<Spring AOP高级——源码实现(1)动态代理技术>中介绍了两种动态代理技术,当然在Spring AOP中代理对象的生成也是运用 ...

  4. Spring Developer Tools 源码分析:二、类路径监控

    在 Spring Developer Tools 源码分析一中介绍了 devtools 提供的文件监控实现,在第二部分中,我们将会使用第一部分提供的目录监控功能,实现对开发环境中 classpath ...

  5. Spring IOC 容器源码分析 - 余下的初始化工作

    1. 简介 本篇文章是"Spring IOC 容器源码分析"系列文章的最后一篇文章,本篇文章所分析的对象是 initializeBean 方法,该方法用于对已完成属性填充的 bea ...

  6. Spring IOC 容器源码分析 - 填充属性到 bean 原始对象

    1. 简介 本篇文章,我们来一起了解一下 Spring 是如何将配置文件中的属性值填充到 bean 对象中的.我在前面几篇文章中介绍过 Spring 创建 bean 的流程,即 Spring 先通过反 ...

  7. Spring IOC 容器源码分析 - 循环依赖的解决办法

    1. 简介 本文,我们来看一下 Spring 是如何解决循环依赖问题的.在本篇文章中,我会首先向大家介绍一下什么是循环依赖.然后,进入源码分析阶段.为了更好的说明 Spring 解决循环依赖的办法,我 ...

  8. Spring IOC 容器源码分析 - 创建原始 bean 对象

    1. 简介 本篇文章是上一篇文章(创建单例 bean 的过程)的延续.在上一篇文章中,我们从战略层面上领略了doCreateBean方法的全过程.本篇文章,我们就从战术的层面上,详细分析doCreat ...

  9. Spring IOC 容器源码分析 - 创建单例 bean 的过程

    1. 简介 在上一篇文章中,我比较详细的分析了获取 bean 的方法,也就是getBean(String)的实现逻辑.对于已实例化好的单例 bean,getBean(String) 方法并不会再一次去 ...

随机推荐

  1. Activity 不只有跳转。功能篇(一)

    Activity生命周期 1:activity四种启动方式 standard,SingleTask,SingleTop,SingleInstance standard:是系统默认的,每次启动该acti ...

  2. CSP2019 Day2T2 划分

    很显然有一个暴力 \(dp\),令 \(dp_{i, j}\) 表示最后一次划分在 \(i\) 上次划分在 \(j\) 的最小花费,令 \(S_i = \sum\limits_{j = 1} ^ i ...

  3. springboot加载外部配置文件

    网上搜集和整理如下(自己已验证过) 1. war包在tomcat中加载外部配置文件 war包运行在独立tomcat下时,如何加载war包外部配置application.properties,以达到每次 ...

  4. SpringBoot + Log4j2使用配置 (转)

    前言 后台程序开发及上线时,一般都会用到Log信息打印及Log日志记录,开发时通过Log信息打印可以快速的定位问题所在,帮助我们快捷开发.程序上线后如遇到Bug或错误,此时则需要日志记录来查找发现问题 ...

  5. 把 Navigation Bar 下面那条线删掉的最简单的办法! — By: 昉

    系统默认的 Navigation Bar 下面一直有条线,翻尽了文档却没找到能把它弄走的相关接口,处女座的简直木法忍啊有木有!!!! 研究了一下navigationBar下的子视图,原来只需要几行代码 ...

  6. 数据分析之客户价值模型(RFM)技术总结

    作者 | leo 管理学中有一个重要概念那就是客户关系管理(CRM),它核心目的就是为了提高企业的核心竞争力,通过提高企业与客户间的交互,优化客户管理方式,从而实现吸引新客户.保留老客户以及将已有客户 ...

  7. Solution -「AGC 036D」「AT 5147」Negative Cycle

    \(\mathcal{Descriprtion}\)   Link.   在一个含 \(n\) 个结点的有向图中,存在边 \(\lang i,i+1,0\rang\),它们不能被删除:还有边 \(\l ...

  8. Vue2.0源码学习(6) - 组件注册

    组件注册 前言 在 Vue.js 中,除了它内置的组件如 keep-alive.component.transition.transition-group 等,其它用户自定义组件在使用前必须注册.在开 ...

  9. 使用Supervisord部署go应用

    nohup nohup 是后台作业的意思, nohup运行的进程将会忽略终端信号运行.即后台运行一个命令.nohup COMMAND &用nohup运行命令可以使命令永久的执行下去,和用户终端 ...

  10. Objective-C 基础教程第三章,面向对象编程基础知

    目录 Objective-C 基础教程第三章,面向对象编程基础知 0x00 前言 0x01 间接(indirection) 0x02 面向对象编程中使用间接 面向过程编程 面向对象编程 0x03 OC ...