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中使用

更多請關注咱們的公衆號：