摘要:創建及準備創建。目前已知關心這個事件的有要注意的是在這個階段,里只有,是的加載工作的起點。原因是注入這些回調接口本身沒有什么意義。在其構造函數內部間接的給注冊了幾個與相關注解的處理器。
相關代碼在: https://github.com/chanjarster/spring-boot-all-callbacks
注:本文基于spring-boot 1.4.1.RELEASE, spring 4.3.3.RELEASE撰寫。
啟動順序Spring boot的啟動代碼一般是這樣的:
@SpringBootApplication public class SampleApplication { public static void main(String[] args) throws Exception { SpringApplication.run(SampleApplication.class, args); } }初始化SpringApplication
SpringApplication#run(Object source, String... args)#L1174
SpringApplication#L1186 -> SpringApplication(sources)#L236
SpringApplication#initialize(Object[] sources)#L256 javadoc
SpringApplication#L257 添加source(復數),SpringApplication使用source來構建Bean。一般來說在run的時候都會把@SpringBootApplication標記的類(本例中是SampleApplication)放到sources參數里,然后由這個類出發找到Bean的定義。
SpringApplication#L261 初始化ApplicationContextInitializer列表(見附錄)
SpringApplication#L263 初始化ApplicationListener列表(見附錄)
SpringApplication#L1186 -> SpringApplication#run(args)#L297,進入運行階段
推送ApplicationStartedEventSpringApplication#run(args)#L297
SpringApplication#L303 初始化SpringApplicationRunListeners (SpringApplicationRunListener的集合)。它內部只包含EventPublishingRunListener。
SpringApplication#L304 推送ApplicationStartedEvent給所有的ApplicationListener(見附錄)。 下面是關心此事件的listener:
LiquibaseServiceLocatorApplicationListener
LoggingApplicationListener(見附錄)
準備EnvironmentSpringApplication#run(args)#L297->#L308->prepareEnvironment(...)#L331準備ConfigurableEnvironment。
SpringApplication#L335 創建StandardEnvironment(見附錄)。
SpringApplication#L336 配置StandardEnvironment,將命令行和默認參數整吧整吧,添加到MutablePropertySources。
SpringApplication#L337 推送ApplicationEnvironmentPreparedEvent給所有的ApplicationListener(見附錄)。下面是關心此事件的listener:
BackgroundPreinitializer
FileEncodingApplicationListener
AnsiOutputApplicationListener
ConfigFileApplicationListener(見附錄)
DelegatingApplicationListener
ClasspathLoggingApplicationListener
LoggingApplicationListener
ApplicationPidFileWriter
可以參考官方文檔了解StandardEnvironment構建好之后,其MutablePropertySources內部到底有些啥東東。
創建及準備ApplicationContextSpringApplication#run(args)#L297
SpringApplication#L311->SpringApplication#createApplicationContext()#L583創建ApplicationContext。可以看到實際上創建的是AnnotationConfigApplicationContext或AnnotationConfigEmbeddedWebApplicationContext。
在構造AnnotationConfigApplicationContext的時候,間接注冊了一個BeanDefinitionRegistryPostProcessor的Bean:ConfigurationClassPostProcessor。經由AnnotatedBeanDefinitionReader構造函數->AnnotationConfigUtils.registerAnnotationConfigProcessors。
SpringApplication#L313->SpringApplication#prepareContext(...)#L344準備ApplicationContext
SpringApplication#L347->context.setEnvironment(environment),把之前準備好的Environment塞給ApplicationContext
SpringApplication#L348->postProcessApplicationContext(context)#L605,給ApplicationContext設置了一些其他東西
SpringApplication#L349->applyInitializers(context)#L630,調用之前準備好的ApplicationContextInitializer
SpringApplication#L350->listeners.contextPrepared(context)->EventPublishingRunListener.contextPrepared,但實際上啥都沒做。
SpringApplication#L366->load#L687,負責將source(復數)里所定義的Bean加載到ApplicationContext里,在本例中就是SampleApplication,這些source是在初始化SpringApplication階段獲得的。
SpringApplication#L367->listeners.contextLoaded(context)->EventPublishingRunListener.contextLoaded。
將SpringApplication自己擁有的ApplicationListener加入到ApplicationContext
發送ApplicationPreparedEvent。目前已知關心這個事件的有ConfigFileApplicationListener、LoggingApplicationListener、ApplicationPidFileWriter
要注意的是在這個階段,ApplicationContext里只有SampleApplication,SampleApplication是Bean的加載工作的起點。
刷新ApplicationContext根據前面所講,這里的ApplicationContext實際上是GenericApplicationContext
->AnnotationConfigApplicationContext或者AnnotationConfigEmbeddedWebApplicationContext
SpringApplication#run(args)#L297
->#L315->SpringApplication#refreshContext(context)#L370
->#L371->SpringApplication#refresh(context)#L759
->#L761->AbstractApplicationContext#refreshAbstractApplicationContext#L507
AbstractApplicationContext#L510->AbstractApplicationContext#prepareRefresh()#L575,做了一些初始化工作,比如設置了當前Context的狀態,初始化propertySource(其實啥都沒干),檢查required的property是否都已在Environment中(其實并沒有required的property可供檢查)等。
AbstractApplicationContext#L513->obtainFreshBeanFactory()#L611,獲得BeanFactory,實際上這里獲得的是DefaultListableBeanFactory
AbstractApplicationContext#L516->prepareBeanFactory(beanFactory)#L625準備BeanFactory
給beanFactory設置了ClassLoader
給beanFactory設置了SpEL解析器
給beanFactory設置了PropertyEditorRegistrar
給beanFactory添加了ApplicationContextAwareProcessor(BeanPostProcessor的實現類),需要注意的是它是第一個被添加到BeanFactory的BeanPostProcessor
給beanFactory設置忽略解析以下類的依賴:ResourceLoaderAware、ApplicationEventPublisherAware、MessageSourceAware、ApplicationContextAware、EnvironmentAware。原因是注入這些回調接口本身沒有什么意義。
給beanFactory添加了以下類的依賴解析:BeanFactory、ResourceLoader、ApplicationEventPublisher、ApplicationContext
給beanFactory添加LoadTimeWeaverAwareProcessor用來處理LoadTimeWeaverAware的回調,在和AspectJ集成的時候會用到
把getEnvironment()作為Bean添加到beanFactory中,Bean Name: environment
把getEnvironment().getSystemProperties()作為Bean添加到beanFactory中,Bean Name: systemProperties
把getEnvironment().getSystemEnvironment()作為Bean添加到beanFactory中,Bean Name: systemEnvironment
AbstractApplicationContext#L520->postProcessBeanFactory(beanFactory),后置處理BeanFactory,實際啥都沒做
AbstractApplicationContext#L523->invokeBeanFactoryPostProcessors(beanFactory),利用BeanFactoryPostProcessor,對beanFactory做后置處理。調用此方法時有四個BeanFactoryPostProcessor:
SharedMetadataReaderFactoryContextInitializer的內部類CachingMetadataReaderFactoryPostProcessor,是在 創建及準備ApplicationContext 2.3 時添加的:#L57
ConfigurationWarningsApplicationContextInitializer的內部類ConfigurationWarningsPostProcessor,是在 創建及準備ApplicationContext 2.3 時添加的:#L60
ConfigFileApplicationListener的內部類PropertySourceOrderingPostProcessor,是在 創建及準備ApplicationContext 2.6 時添加的:#L158->#L199->#L244
ConfigurationClassPostProcessor,負責讀取BeanDefinition是在 創建及準備ApplicationContext 1.1 時添加的
AbstractApplicationContext#L526->registerBeanPostProcessors(beanFactory),注冊BeanPostProcessor
AbstractApplicationContext#L529->initMessageSource()#L704,初始化MessageSource,不過其實此時的MessageSource是個Noop對象。
AbstractApplicationContext#L532->initApplicationEventMulticaster()#L739,初始化ApplicationEventMulticaster。
AbstractApplicationContext#L535->onRefresh()#L793,這個方法啥都沒做
AbstractApplicationContext#L538->registerListeners()#L801,把自己的ApplicationListener注冊到ApplicationEventMulticaster里,并且將之前因為沒有ApplicationEventMulticaster而無法發出的ApplicationEvent發送出去。
AbstractApplicationContext#L541->finishBeanFactoryInitialization#L828。注意#L861,在這一步的時候才會實例化所有non-lazy-init bean,這里說的實例化不只是new而已,注入、BeanPostProcessor都會執行。
AbstractApplicationContext#L544->finishRefresh()#L869。
在#L877發送了ContextRefreshedEvent
調用 ApplicationRunner 和 CommandLineRunnerSpringApplication#run(args)#L297
->afterRefresh(context, applicationArguments)#L316
->callRunners(context, args)#L771
->#L774 先后調用了當前ApplicationContext中的ApplicationRunner和CommandLineRunner。關于它們的相關文檔可以看這里。
需要注意的是,此時的ApplicationContext已經刷新完畢了,該有的Bean都已經有了。
推送ApplicationReadyEvent or ApplicationFailedEventSpringApplication#run(args)#L297->listeners.finished(context, null)#L317
間接地調用了EventPublishingRunListener#getFinishedEventEventPublishingRunListener#L96,發送了ApplicationReadyEvent或ApplicationFailedEvent
javadoc 相關文檔
加載方式:讀取classpath*:META-INF/spring.factories中key等于org.springframework.context.ApplicationContextInitializer的property列出的類
排序方式:AnnotationAwareOrderComparator
已知清單1:spring-boot-1.4.1.RELEASE.jar!/META-INF/spring.factories
ConfigurationWarningsApplicationContextInitializer(優先級:0)
ContextIdApplicationContextInitializer(優先級:Ordered.LOWEST_PRECEDENCE - 10)
DelegatingApplicationContextInitializer(優先級:無=Ordered.LOWEST_PRECEDENCE)
ServerPortInfoApplicationContextInitializer(優先級:無=Ordered.LOWEST_PRECEDENCE)
已知清單2:spring-boot-autoconfigure-1.4.1.RELEASE.jar!/META-INF/spring.factories
SharedMetadataReaderFactoryContextInitializer(優先級:無=Ordered.LOWEST_PRECEDENCE)
AutoConfigurationReportLoggingInitializer(優先級:無=Ordered.LOWEST_PRECEDENCE)
ApplicationListenerjavadoc 相關文檔
加載方式:讀取classpath*:META-INF/spring.factories中key等于org.springframework.context.ApplicationListener的property列出的類
排序方式:AnnotationAwareOrderComparator
已知清單1:spring-boot-1.4.1.RELEASE.jar!/META-INF/spring.factories中定義的
ClearCachesApplicationListener(優先級:無=Ordered.LOWEST_PRECEDENCE)
ParentContextCloserApplicationListener(優先級:Ordered.LOWEST_PRECEDENCE - 10)
FileEncodingApplicationListener(優先級:Ordered.LOWEST_PRECEDENCE)
AnsiOutputApplicationListener(優先級:ConfigFileApplicationListener.DEFAULT_ORDER + 1)
ConfigFileApplicationListener(優先級:Ordered.HIGHEST_PRECEDENCE + 10)
DelegatingApplicationListener(優先級:0)
LiquibaseServiceLocatorApplicationListener(優先級:無=Ordered.LOWEST_PRECEDENCE)
ClasspathLoggingApplicationListener(優先級:LoggingApplicationListener的優先級 + 1)
LoggingApplicationListener(優先級:Ordered.HIGHEST_PRECEDENCE + 20)
已知清單2:spring-boot-autoconfigure-1.4.1.RELEASE.jar!/META-INF/spring.factories中定義的
BackgroundPreinitializer
SpringApplicationRunListenerjavadoc
加載方式:讀取classpath*:META-INF/spring.factories中key等于org.springframework.boot.SpringApplicationRunListener的property列出的類
排序方式:AnnotationAwareOrderComparator
已知清單:spring-boot-1.4.1.RELEASE.jar!/META-INF/spring.factories定義的
org.springframework.boot.context.event.EventPublishingRunListener(優先級:0)
EnvironmentPostProcessorEnvironmentPostProcessor可以用來自定義StandardEnvironment(相關文檔)。
加載方式:讀取classpath*:META-INF/spring.factories中key等于org.springframework.boot.env.EnvironmentPostProcessor的property列出的類
排序方式:AnnotationAwareOrderComparator
已知清單:spring-boot-1.4.1.RELEASE.jar!/META-INF/spring.factories定義的
CloudFoundryVcapEnvironmentPostProcessor(優先級:ConfigFileApplicationListener.DEFAULT_ORDER - 1)
SpringApplicationJsonEnvironmentPostProcessor(優先級:Ordered.HIGHEST_PRECEDENCE + 5)
BeanPostProcessorjavadoc 相關文檔
用來對Bean實例進行修改的勾子,根據Javadoc ApplicationContext會自動偵測到BeanPostProcessor Bean,然后將它們應用到后續創建的所有Bean上。
BeanFactoryPostProcessor和BeanDefinitionRegistryPostProcessor相關文檔
PostProcessorRegistrationDelegate負責調用BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor。
BeanDefinitionRegistryPostProcessor在BeanFactoryPostProcessor之前被調用。
*Aware是一類可以用來獲得Spring對象的interface,這些interface都繼承了Aware,已知的有:
ApplicationEventPublisherAware
NotificationPublisherAware
MessageSourceAware
EnvironmentAware
BeanFactoryAware
EmbeddedValueResolverAware
ResourceLoaderAware
ImportAware
LoadTimeWeaverAware
BeanNameAware
BeanClassLoaderAware
ApplicationContextAware
@Configuration 和 Auto-configuration@Configuration替代xml來定義BeanDefinition的一種手段。Auto-configuration也是定義BeanDefinition的一種手段。
這兩者的相同之處有:
都是使用@Configuration注解的類,這些類里都可以定義@Bean、@Import、@ImportResource。
都可以使用@Condition*來根據情況選擇是否加載
而不同之處有:
加載方式不同:
普通@Configuration則是通過掃描package path加載的
Auto-configuration的是通過讀取classpath*:META-INF/spring.factories中key等于org.springframework.boot.autoconfigure.EnableAutoConfiguration的property列出的@Configuration加載的
加載順序不同:普通@Configuration的加載永遠在Auto-configuration之前
內部加載順序可控上的不同:
普通@Configuration則無法控制加載順序
Auto-configuration可以使用@AutoConfigureOrder、@AutoConfigureBefore、@AutoConfigureAfter
以下情況下Auto-configuration會在普通@Configuration前加載:
Auto-configuration如果出現在最初的掃描路徑里(@ComponentScan),就會被提前加載到,然后被當作普通的@Configuration處理,這樣@AutoConfigureBefore和@AutoConfigureAfter就沒用了。參看例子代碼里的InsideAutoConfiguration和InsideAutoConfiguration2。
Auto-configuration如果提供BeanPostProcessor,那么它會被提前加載。參見例子代碼里的BeanPostProcessorAutoConfiguration。
Auto-configuration如果使用了ImportBeanDefinitionRegistrar,那么ImportBeanDefinitionRegistrar會被提前加載。參見例子代碼里的ImportBeanDefinitionRegistrarAutoConfiguration。
Auto-configuration如果使用了ImportSelector,那么ImportSelector會被提前加載。參見例子代碼里的UselessDeferredImportSelectorAutoConfiguration。
參考EnableAutoConfiguration和附錄EnableAutoConfigurationImportSelector了解Spring boot內部處理機制
AnnotatedBeanDefinitionReader這個類用來讀取@Configuration和@Component,并將BeanDefinition注冊到ApplicationContext里。
ConfigurationClassPostProcessorConfigurationClassPostProcessor是一個BeanDefinitionRegistryPostProcessor,負責處理@Configuration。
需要注意一個煙霧彈:看#L296->ConfigurationClassUtils#L209。而order的值則是在ConfigurationClassUtils#L122從注解中提取的。
這段代碼似乎告訴我們它會對@Configuration進行排序,然后按次序加載。
實際上不是的,@Configuration是一個遞歸加載的過程。在本例中,是先從SampleApplication開始加載的,而事實上在這個時候,也就只有SampleApplication它自己可以提供排序。
而之后則直接使用了ConfigurationClassParser,它里面并沒有排序的邏輯。
關于排序的方式簡單來說是這樣的:@Configuration的排序根據且只根據@Order排序,如果沒有@Order則優先級最低。
ConfigurationClassParser前面講了ConfigurationClassPostProcessor使用ConfigurationClassParser,實際上加載@Configuration的工作是在這里做的。
下面講以下加載的順序:
以SampleApplication為起點開始掃描
掃描得到所有的@Configuration和@Component,從中讀取BeanDefinition并導入:
如果@Configuration注解了@Import
如果使用的是ImportSelector,則遞歸導入
如果使用的是ImportBeanDefinitionRegistrar,則遞歸導入
如果使用的是DeferredImportSelector,則僅收集不導入
如果@Configuration注解了@ImportResource,則遞歸導入
迭代之前收集的DeferredImportSelector,遞歸導入
那Auto-configuration在哪里呢?
實際上是在第3步里,@SpringBootApplication存在注解@EnableAutoConfiguration,它使用了EnableAutoConfigurationImportSelector,
EnableAutoConfigurationImportSelector是一個DeferredImportSelector,所以也就是說,Auto-configuration是在普通@Configuration之后再加載的。
順帶一提,如果Auto-configuration里再使用DeferredImportSelector,那么效果和使用ImportSelector效果是一樣的,不會再被延后處理。參見例子代碼里的UselessDeferredImportSelectorAutoConfiguration。
EnableAutoConfigurationImportSelectorEnableAutoConfigurationImportSelector負責導入Auto-configuration。
它利用AutoConfigurationSorter對Auto-configuration進行排序。邏輯算法是:
先根據類名排序
再根據@AutoConfigureOrder排序,如果沒有@AutoConfigureOrder則優先級最低
再根據@AutoConfigureBefore,@AutoConfigureAfter排序
內置類說明 LoggingApplicationListenerLoggingApplicationListener用來配置日志系統的,比如logback、log4j。Spring boot對于日志有詳細解釋,如果你想自定義日志配置,那么也請參考本文中對于LoggingApplicationListener的被調用時機的說明以獲得更深入的了解。
StandardEnvironmentStandardEnvironment有一個MutablePropertySources,它里面有多個PropertySource,PropertySource負責提供property(即property的提供源),目前已知的PropertySource實現有:MapPropertySource、SystemEnvironmentPropertySource、CommandLinePropertySource等。當StandardEnvironment查找property值的時候,是從MutablePropertySources里依次查找的,而且一旦查找到就不再查找,也就是說如果要覆蓋property的值,那么就得提供順序在前的PropertySource。
ConfigFileApplicationListenerConfigFileApplicationListener用來將application.properties加載到StandardEnvironment中。
ConfigFileApplicationListener內部使用了EnvironmentPostProcessor(見附錄)自定義StandardEnvironment
ApplicationContextAwareProcessorApplicationContextAwareProcessor實現了BeanPostProcessor接口,根據javadoc這個類用來調用以下接口的回調方法:
EnvironmentAware
EmbeddedValueResolverAware
ResourceLoaderAware
ApplicationEventPublisherAware
MessageSourceAware
ApplicationContextAware
AnnotationConfigApplicationContext根據javadoc,這個類用來將@Configuration和@Component作為輸入來注冊BeanDefinition。
特別需要注意的是,在javadoc中講到其支持@Bean的覆蓋:
In case of multiple @Configuration classes, @Bean methods defined in later classes will override those defined in earlier classes. This can be leveraged to deliberately override certain bean definitions via an extra @Configuration class.
它使用AnnotatedBeanDefinitionReader來讀取@Configuration和@Component。
AnnotatedBeanDefinitionReaderAnnotatedBeanDefinitionReader在其構造函數內部間接(AnnotationConfigUtils#L145)的給BeanFactory注冊了幾個與BeanDefinition相關注解的處理器。
ConfigurationClassPostProcessor
AutowiredAnnotationBeanPostProcessor
RequiredAnnotationBeanPostProcessor
CommonAnnotationBeanPostProcessor
EventListenerMethodProcessor
PersistenceAnnotationBeanPostProcessor
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/66039.html
摘要:在一個初春的下午,甲跟我說,要在啟動服務的時候,設置表自增的起始值。寫完啟動項,那么再把退出也說一下每一個都應該向注冊一個鉤子函數來確保能優雅地關閉。后面退出部分翻譯地磕磕碰碰的,有不對的地方歡迎指正。原創不易,感謝支持。 在一個初春的下午,甲跟我說,要在Spring Boot啟動服務的時候,設置表自增的起始值。于是我用屁股想了一下,不就是在main方法里折騰嘛。后來實際操作了一把,發...
摘要:代碼示例本文示例讀者可以通過查看下面倉庫的中的三個項目如果您對這些感興趣,歡迎收藏轉發給予支持以下專題教程也許您會有興趣基礎教程基礎教程 有很多讀者問過這樣的一個問題:雖然使用Swagger可以為Spring MVC編寫的接口生成了API文檔,但是在微服務化之后,這些API文檔都離散在各個微服務中,是否有辦法將這些接口都整合到一個文檔中?之前給大家的回復都只是簡單的說了個思路,昨天正好...
摘要:總結基于構建相對來說還是比較便捷的,其中注解使得代碼更加簡潔,本次用到注解再匯總下,有時間的話可以深入理解下其背后的原理申明讓自動給程序進行必要的配置。風格的控制器提供路由信息,負責到中的具體函數的映射一般用于修飾層的組件自動導入依賴的 本文主要記錄搭建RESTful API標準工程,包含比較推薦的工程結構,掌握一些基本注解,并引入Swagger 新建一個項目 通過Spring Ini...
摘要:實例定義一個實現,并納入到容器中進行處理啟動定義一個實現,并納入到容器處理應用已經成功啟動啟動類測試,也可以直接在容器訪問該值,配置參數,然后執行啟動類打印結果接口發現二者的官方一樣,區別在于接收的參數不一樣。引言 我們在使用SpringBoot搭建項目的時候,如果希望在項目啟動完成之前,能夠初始化一些操作,針對這種需求,可以考慮實現如下兩個接口(任一個都可以) org.springfram...
摘要:除了,還有十余種,有的是特定操作,比如轉儲內存日志有的是信息展示,比如顯示應用健康狀態。 showImg(http://ww1.sinaimg.cn/large/006tNc79gy1g5qb2coyfoj30u00k0tan.jpg); 前言 隨著線上應用逐步采用 SpringBoot 構建,SpringBoot應用實例越來多,當線上某個應用需要升級部署時,常常簡單粗暴地使用 kil...
閱讀 3916·2021-09-09 09:33
閱讀 1773·2021-09-06 15:14
閱讀 1919·2019-08-30 15:44
閱讀 3074·2019-08-29 18:36
閱讀 3765·2019-08-29 16:22
閱讀 2095·2019-08-29 16:21
閱讀 2530·2019-08-29 15:42
閱讀 1647·2019-08-29 11:00