Spring Leader分享：Spring Framework之再探Core Container 上

特别说明

这是一个由simviso团队进行的关于Spring Framework 5.2版本内容分享的视频翻译文档，分享者是Spring Framework 5.2项目leader。方便你们在将来某个时候回顾的时候能够快速定位内容。

视频地址：

【国外前沿技术分享-后端-中文字幕】Spring Framework之再探Core Container 上

【国外前沿技术分享-后端-中文字幕】Spring Framework之再探Core Container 中

【国外前沿技术分享-后端-中文字幕】Spring Framework之再探Core Container 下

视频翻译文字版权归 simviso全部，未经受权，请勿转载：

顺带推荐一个专业的程序员后端微信群的圈子：

介绍

好，咱们开始

欢迎回来这个房间，让咱们一块儿进入到Spring 5.2的分享环节中来

在上午进行的Spring过去的15年这个主题分享中我看到你有在

总之，很感谢再次看到你

因此，这很适合接下来要讲的内容，固然，这部份内容是独立存在的

咱们将要介绍咱们在Spring Framework 5中使用最新技术的情况

特别是在5以后，我经历了咱们在Spring Framework 5.0 和 5.1中的主题和所作的设计决策，这与今天整个主题密切相关

标题已经给出了，即Spring Framework之再探Core Container

Spring Framework 做为Spring开源项目中的一个，你能够从github上找到

这个项目包含了整个core web stack，即web Mvc以及webflux

这也是我担任Spring Framework项目负责人平时所作的工做内容

所以，全部Spring Framework项目有关的内容都在个人职责范围内

不只仅做为技术主管，更少它们的发布管理者，同时也是Spring Framework相关事务的主要协调纽带

ok，目前 Spring 5.2仍处于开发阶段

我接下来会讨论的东西也并未彻底成型，我但愿咱们今天所要讨论的东西能最大程度的保留

不过，Spring Framework 5.2会在七月份推出第一个完整RC版本

so，大家以后很快就能看到了

GA版本（general availability）会在九月份推出

ok

我这里有几个主题，经过对它们进行集中的演示

咱们来看看核心容器，咱们将从几个不一样的角度来看Spring Framework作了什么

首先，让咱们看看咱们用核心API作什么

针对core API的迭代是咱们每一年都在作的一件事情

对咱们来说，主版本在咱们的版本控制方案里的意义在于，它表明了咱们最低也要基于这个标准进行开发 同时须要咱们去从新审视整个框架代码库和整个框架API层面

也就是说这些核心API会进行大规模的迭代，实际上，这些大变化也只会发生在 Spring 3, 4, 5 这些主版本中

Java 8风格的演进

Spring Framework 5中的核心API 的迭代是以Java 8为基准进行的

整个框架代码库，特别是它的全部API和SPI都在使用Java 8的特性

Java 8作了不少隐式实现的支持（咱们不须要刻意去实现），甚至在Spring Framework 4中 特别是在Spring Framework 3中，咱们就已经进行了这方面的支持（自动化的隐式实现）

因此你不多有注意到这个框架不是基于Java 8的 整个框架使用起来感受就像基于Java 8同样（Spring Framework 4就是这样）

但Spring Framework 5真的是基于Java 8的，在少数状况下你会感受到不同 咱们在内部作了大量代码优化，有趣的是许多优化都来自于社区的贡献

在Java 8代码风格和实现风格的升级上面为咱们作了不少贡献

经过Java8能够解决低效问题，也就意味着这个转变过程咱们将持续下去 相应的，我也在关注众多关于这方面的代码贡献

咱们甚至还有一个来自俄罗斯的贡献者，在大约三个月的时间中向咱们发送了50个 Pull Request

全部的这些都与咱们遗漏的Java 8的代码风格升级有关

从咱们本身设想的角度，咱们尽本身所能作了力所能及的改变，固然，过程当中咱们也使用了趁手的工具

可是依然还有改进空间

很高兴社区可以接受这一点

接着，咱们言归正传

在框架自身的API中，咱们终于能够基于Java8来设计咱们的核心方法

so, 像java.util包下的optional，stream 以及函数式接口(如：supplier，consumer，predicate)等如今能够在核心框架api中使用

你能够在你的代码中直接引用核心框架的api，亦或者你能够实现这些函数式接口

咱们来讨论一些像BeanFactory, JdbcTemplate, TransactionSynchronization 这些可能会在咱们代码中进行使用的API类型

因此这里进行了大量的修改，咱们如今能够直接经过一些函数式接口(java.util.function)进行适配器重载方法的迭代

重载方法接受Java.time类型（例如使用Instant、Duration和Clock来替换java.util.Date或毫秒(long)）

在整个代码库中，这些只是表面上的API修订，一般咱们是不会单独作这些的 可是咱们有尝试在整个核心框架库中找到全部能够进行改进的地方进行迭代升级

除了引用Java 8 API类型以外，还有另外一个很是重要的东西 Java 8语言提供了一个新的功能，就是接口中的默认方法(default)

大家可能已经注意到了(或许尚未注意到)这些接口默认方法背后给咱们带来怎样的好处

特别是基于现有接口中的许多相应方法实现均可以移除掉

你可能只是对一个特定接口的一个、或两个、或三个、或四个方法的实现感兴趣，如今无需使用适配器模式进行相关实现

你只须要直接实现接口方法就能够了，拿TransactionSynchronization来说，咱们只须要重写afterCommit()方法 同时其余方法直接忽略便可，接口中已经有默认实现了。这也是利用了Java 8 default方法的特性

这对于咱们API设计者而言，这确实是咱们手中的利器

若是咱们想要在接口中引入新的方法，咱们就能够将default做为主要实现手段

你没有必要去实现它，咱们能够提供一个默认方法以便现有的实现依然能够继续使用

这里，咱们只是使用了几个经常使用的类型(BeanFactory, JdbcTemplate, TransactionSynchronization)来对前面的内容作一个简单的表达

可空性处理

在咱们API修订中另一个同等重要的部分就是可空性处理(处理null的能力，Nullability)

在这以前，咱们实现的方式和Java自身是同样的

在没有太多显性声明的时候，一些Java老码农可能会说在这里抛空或者不能抛空 因此相对的，方法的返回值可能为空也可能不为空

这是在Java中处理可空引用的老办法

在Spring Framework 5中展示了一个彻底不一样的模式

提供了对可空（@Nullable）和非空（@NonNull）的严格声明

在默认状况下能够用在全部的包、核心框架包和异常中，这样就能够在全部能够为NULL的东西上面加上@Nullable注解

@Nullable可用于构造函数参数，方法参数，特别也能够用于返回值（好比ObjectProvider中的getIfAvailable()方法）

在二次迭代时，咱们能够将@Nullable应用到咱们的字段中,也能够经过针对特定对象的当前状态来验证咱们的假设

这是一个颇有用的实践

结果证实这是一个对咱们很是有用的实践，它能够确保咱们在代码中不会遗漏任何潜在的可空性处理

同时能够消除效率低下的问题

同时也能够帮咱们找到冗余(重复性防护)代码

在任何一个执行路径中，它会一直对那些永不为Null的对象进行检查

咱们该怎么知道？

咱们用的最多的工具就是InteliJ IDEA，它支持@Nullable注解，咱们只须要将它配置成@Nullable InteliJ会立马知道@Nullable在咱们spring中的使用规则，接着InteliJ会为咱们提供一些开箱即用的检查

更重要的是，咱们称之为 constant conditions &exceptions，即背后表明隐式实现了条件和异常判断

假设你代码中有@Nullable 方面的bug，那IDEA经过这些开箱即用的检查便可告诉咱们问题所处位置

当它容许为Null时，你无需进行检查，而另外一方面你又对Null作了检查，也就是说，它实际上是必须不能为Null

所以，这主要是针对Java层面的事情，由于咱们的核心框架就是用Java实现的

咱们用的最多的地方就是拿它来校验咱们的代码

若是你选择将Spring和Kotlin一块儿使用，那么效果更加显著 固然Kotlin 同时也是Spring开发支持的推荐语言

从Spring Framework 5.2开始，经过Kotlin的编译器，你将拥有一个更强大的可空性处理模型

在Kotlin类型系统中，若是你没有对基本类型和引用类型进行@Nullable声明，这意味着永远不容许为空

Kotlin编译器会对其使用断言（检查/验证），所作的验证调用和你专门在Java API中所设定的同样

相比之下，在若是在你正在调用Java API中，想要作到这种效果，就要进行特别明确声明，即它永远不会返回另外一个值

经过在咱们的代码库中使用那些简洁的注解，使得咱们框架的API对Kotlin的支持变得比之前更加友好

那么在使用Kotlin开发过程当中有一个十分经常使用的经验 即全部Spring Framework中你能够调用的API都具备这个明确地可空性处理规则

在某些场景中，咱们甚至增长和修改了可空性规则

因此在调用Spring Framework 5早期版本中的某些API的时候，你可能会接收到一个空值

可是在Spring Framework 5如今的版本中，咱们增强了对它的约束，这种状况如今就不会再发生了

因此在某些场景中，咱们对可空性进行了适应性的修正

这对Java而言一样颇有用

若是大家的项目代码基于Java和Spring 5，那么大家所能作的是用idea去针对大家的代码进行检查

由于若是你的代码调用的是Spring框架中的代码 那么idea就会理解Spring代码中的@Nullable注解并对其进行可空性判断

idea会对你基于Spring Framework的代码进行条件验证，同时也会指出你设定的那些无心义的条件

因此这对Java开发而言颇有价值

经过ObjectProvider来阐述相关迭代

Okay

来看几个API修订的例子，ObjectProvider类已经面目一新 从Spring Framework 4.3到5增长了很多新方法（@Nullable以及增长函数式支持）

这是一个引用(经过它能够获取到目标Bean)，即经过它能够对目标依赖进行一些间接处理

你能够经过注解注入或者经过BeanFactory.getBeanProvider()得到这个目标类型的引用

这样你手里就有了一个能够获取目标类型的ObjectProvider对象

你能够经过ObjectProvider来获得目标实例，若是不可用它将返回NULL，就像这里

根据定义在（这个）getIfAvailable()中，若是不可用则返回Null，因此它用@Nullable标注

这个例子很好的阐述了可空性注解（getIfAvailable()）

对于getIfUnique()也是同样，只有在有一个惟一的目标实例 而不是多个实例的状况下，你才真正获得一个对象，不然不会

这些方法在Spring Framework4.3以前就已经存在了

在5.2中咱们只是对它们添加了注解，这样可使它的语义很是清晰和美观，由此它们能够返回NULL

同时咱们趁机添加了重载方法

为了永不返回Null，咱们特别声明了getIfAvailable(Supplier) 这个重载方法 传入的参数类型为java.util.function.Supplier的Java 8 Lambda表达式

这里若是目标对象不可用，那就采用一个默认值 意思就是要么从BeanFactory得到目标对象，要么经过Supplier获得默认值，也就意味着你永远不会获得Null

因此这个方法签名上面咱们并无用@Nullable，返回值也不为空

这里有一个更具函数式风格的ifAvailable(Consumer)方法 若是ObjectProvider能够获取到目标对象，则执行Cunsumer中的操做(Lambda表达式)

在Java中函数式风格真的很nice

经过ObjectProvider这几个重载方法，相信你已经颇有感受了

经过这些风格的改变，你能够告诉core container你要作什么动做(函数式动做)

ObjectProvider也提供了几个用于检索多个匹配实例的方法

这没什么可惊讶的

为此咱们集成了java.util.stream来进行流式操做

因此在ObjectProvider中提供了两个新方法 stream()和orderedStream()

从字面上就能够看出它的工做原理相似于Collection.stream()

若是你在Java8风格下对一个集合使用过流式处理

这是一个很是类似的模式，实际上它不是一个集合 它是一个ObjectProvider对象，经过它能够获取到多个目标Bean实例

它虽不是名义上的集合，但它能够像集合同样进行流交互

另外，当你在启动的时候，你会配置一个application context，你也能够在Spring Framework 5中选择这种方式进行编程

在Spring 5中，你就能够作到这种程度

当咱们结合stereotype注解(经常使用的四个有@Component，@Controller，@Repository，@Service) 在classpath中进行组件查找时能够经过这里（指图中）来替换classpath扫描

如图所示

这是百分之百会发生的，没有什么后台工做

当你在Spring中有很明肯定义的时候（通俗的讲，就是种瓜得瓜种豆得豆）

若是你不说咱们须要扫描某个类，那么咱们也不会

同时，做为主要入口点的generic就是用来达到这些目的的 GenericApplicationContext 是一个有着12年历史的一个类

如今，咱们能够经过像 registerBean(supplier)这样的方法来获取一个目标类型 同时咱们能够设定一个supplier实例做为参数传入

咱们在这里使用了些Java 8风格的API

这个registerBean(Foo.class)是基于标准手段来构造一个实例，若是没有其它说明的话，那么就基于默认构造器

你可能对这个registerBean(Bar.class,...)比较感兴趣 咱们注册一个Bar.class的组件，里面内联一个Lambda表达式来给咱们建立一个新的Bar实例

这个内联的表达式是Java.util.function.Supplier实现，它有点像函数式风格的工厂方法

这里并无工厂方法

有的只是这个内联的Lambda表达式，没有额外的组件，没有配置类，没有Bean方法，没有注解

甚至于不须要反射，直接经过一个Supplier实例来进行

若是这是一个Scope组件或Prototype组件，每次调用的时候都须要一个新的Bar实例 咱们在这个动态指令调用中，咱们不须要进行反射，直接经过调用这个Supplier实例来获得

这里有几个变体 若是你想的话，你能够传入一个ObjectProvider

咱们假设有这样一个Bar，它是由一个目标类型为Foo.class的Object对象或实例来构造的 它能够经过这种编程方式来绑定（如图所示）

还有些其余的小事情

咱们来看下面的变体

它里面有多个Lambda表达式 它不只仅有Supplier实例（能够用于建立Bar实例）

这里还有一个

实际上能够有更多，咱们将它们称之为 BeanDefinitionCustomizer

基于这个，你能够获得一个 BeanDefinition（即咱们将要注册的元数据对象） 的回调

这些BeanDefinition一样能够经过注解来建立，咱们也能够经过在XML中进行Bean定义建立

但这里咱们是用了代码的形式来实现

在它注册到这个容器以前，你能够设定一些特定的标志或限定符之类的 如lazy-init或者是在BeanDefinition中添加一些限定符

这个和你添加Lazy注解或者添加Qualifier注解或者其它一些相似的注解，产生的效果是同样的

这只是给大家留个印象，并非今天的重点

这一切一样适用于Kotlin，咱们在Spring Framework 5中所作的一切均可以在Kotlin中使用

更多请关注咱们的公众号：