Spring多種啟動初始化方案，看這篇就夠了
目錄
- 前言
- CommandLineRunner
- ApplicationRunner
- ApplicationListener
- @PostConstruct
- InitializationBean
- 總結
前言
我們經常有一些業務需求，需要在項目啟動后執行相關的業務代碼，如：數據的初始化業務。今天我們來梳理一下有哪些方案?
CommandLineRunner
CommandLineRunner是一個接口，通過實現它，我們可以在Spring應用成功啟動之后執行一些代碼片段
我們先定義個User實體Bean
下面我們定義一個類實現CommandLineRunner接口
當 Spring Boot 在應用上下文中找到 CommandLineRunner bean，它將會在應用成功啟動之后調用 run() 方法，并傳遞用于啟動應用程序的命令行參數
java -jar demo-0.0.1-SNAPSHOT.jar --foo=bar --name=gujch
啟動執行結果
小結：
- 命令行傳入的參數并沒有被解析，而只是顯示出我們傳入的字符串內容 --foo=bar，--name=gujch
- 在重寫的 run() 方法上有 throws Exception 標記，Spring Boot 會將 CommandLineRunner 作為應用啟動的一部分，如果運行 run() 方法時拋出 Exception，應用將會終止啟動
- 當有多個 CommandLineRunner 時，將會按照 @Order 注解中的數字從小到大
如果我們只是想簡單的獲取以空格分隔的命令行參數，那 MyCommandLineRunner 就足夠使用了
ApplicationRunner
上面提到，通過命令行啟動并傳遞參數，MyCommandLineRunner 不能解析參數，如果要解析參數，那我們就要用到 ApplicationRunner 參數了
執行結果
到這里我們可以看出:
同 MyCommandLineRunner 相似，但 ApplicationRunner 可以通過 run 方法的 ApplicationArguments 對象解析出命令行參數，并且每個參數可以有多個值在里面，因為 getOptionValues 方法返回 List數組
在重寫的 run() 方法上有 throws Exception 標記，Spring Boot 會將 ApplicationRunner 作為應用啟動的一部分，如果運行 run() 方法時拋出 Exception，應用將會終止啟動
ApplicationRunner 也可以使用 @Order 注解進行排序，從啟動結果來看，它與 CommandLineRunner 共享 order 的順序
我們來看看源碼，CommandLineRunner 和 ApplicationRunner 是在何時被調用的呢?
SpringApplication.java類中callRunners方法
上面可以看到spring獲取CommandLineRunner 和 ApplicationRunner Bean會放到List中，然后一起排序，所以@Order排序是共享的
ApplicationListener
如果我們不需要獲取命令行參數時，我們可以將啟動邏輯綁定到 Spring 的 ApplicationReadyEvent 上
執行結果
ApplicationReadyEvent 當且僅當 在應用程序就緒之后才被觸發。
啟動順序Order不與CommandLineRunner和ApplicationRunner共享
如果我們不需要獲取命令行參數，我們可以通過 ApplicationListener
@PostConstruct
創建啟動邏輯的另一種簡單解決方案是提供一種在 bean 創建期間由 Spring 調用的初始化方法。我們要做的就只是將 @PostConstruct 注解添加到方法中：
執行結果
從上面運行結果可以看出:
1)Spring 創建完 bean之后 (在啟動之前)，便會立即調用 @PostConstruct 注解標記的方法，因此我們無法使用 @Order 注解對其進行自由排序，因為它可能依賴于 @Autowired插入到我們 bean 中的其他 Spring bean。
2)相反，它將在依賴于它的所有 bean 被初始化之后被調用
@PostConstruct 方法固有地綁定到現有的 Spring bean，因此應僅將其用于此單個 bean 的初始化邏輯;
@PostConstruct應用場景：
在生成對象時候做一些初始化操作，而這些初始化操作又依賴于依賴注入(populateBean)，那么就無法在構造函數中實現。這時，可以使用@PostConstruct注解一個方法來完成初始化，@PostConstruct注解的方法將會在依賴注入完成后被自動調用。
InitializingBean
與 @PostConstruct 解決方案非常相似，我們可以實現 InitializingBean 接口，并讓 Spring 調用某個初始化方法:
執行結果
@PostConstruct 和 afterPropertiesSet 區別
1、afterPropertiesSet，顧名思義「在屬性設置之后」，調用該方法時，該 bean 的所有屬性已經被 Spring 填充。如果我們在某些屬性上使用 @Autowired(常規操作應該使用構造函數注入)，那么 Spring 將在調用afterPropertiesSet 之前將 bean 注入這些屬性。但 @PostConstruct 并沒有這些屬性填充限制
2、所以
InitializingBean.afterPropertiesSet 解決方案比使用 @PostConstruct 更安全，因為如果我們依賴尚未自動注入的 @Autowired 字段，則 @PostConstruct 方法可能會遇到 NullPointerExceptions
總結
從上面的例子中我們就可以發現各個啟動方案的順序
針對Bean實體啟動初始化 順序
Construct >> @Autowired(依賴注入) >> @postConstruct >> InitializingBean
針對整體項目啟動 順序
CommandLineRunner和ApplicationRunner >> ApplicationListener
