你好呀，我是歪歪。

这周我在 Spring 的 github 上晃荡的时候，一个 issues 引起了我的趣味。

这篇文章，是我顺着这个 issues 往下写，始于它，然而不止于它：

https://github.com/spring-pro...

这个 issues 题目翻译过去，就是说心愿 @Async 这个注解可能反对占位符或 SpEL 表达式。

而我关注到这个 issues 的起因，齐全是因为我之前写过 @Async 相干的文章，看着眼生，就顺手点进来看了一下。

在这个问题外面，提到了一个编号为 27775 的 issues：

https://github.com/spring-pro...

这个说的是个啥事儿呢？

预计你看一眼我截图中标注的中央也就看进去了，他想把线程池的名称放到配置文件外面去。而这个需要我感觉并不奇怪，基于 Spring 框架来说，是一个很正当的需要。

搞个 Demo

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

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

而后有一个被 @Async 注解润饰的办法，而这个注解指定了一个值为 why 的 value，表明要应用名称为 why 的这个线程池：

接着咱们还须要一个 Controller，触发一下：

最初在启动类上加上 @EnableAsync 注解，把我的项目启动起来。

调用上面的链接，发动调用：

http://127.0.0.1:8085/insertU...

输入后果如下：

阐明配置失效了。

而后，提出 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...

我就间接把文章中的例子拿进去给你说一下。

咱们用 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/0...

官网在去年的 SpringOne 大会上就发表了：Spring 6.0 和 Spring Boot 3 这两大框架的 JDK 基线版本是 17。

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

而我，作为一个技术爱好者的角度来说：这是坏事，得反对，大力支持。

然而，作为一个写着 CRUD 的 Java 从业者来说：想想降级之后各种兼容性问题就头疼，所以心愿这个拥抱不要产生在我短暂的职业生涯中。去让那帮年轻力壮，刚刚入行的小伙子们去折腾吧。

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

历史代码中这么多用 instanceof 的中央，我只有在 6.0 分支外面，把这些中央都换成新个性的写法，那岂不是一个更简略的奉献源码的形式？

然而，在提交 issues 之前，个别流程都是要先去查问一下有没有相似的提交。

所以在干这事之前，我还是先沉着的查问了一下。

一查，我都笑了...

我都能想到，必定其他人也能想到，果然有人曾经姗姗来迟了。

比方这里：

https://github.com/spring-pro...

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

而后，官网还在外面小小的吐槽了一波：

简略来说就是：老哥，这样的小改良，就还是不要提 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/20...

将来一段时间，是 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技术]，欢送关注，第一工夫接管最新文章。