引言
先看下最基本的啓動 Spring 容器的例子:
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationf.xml");
}
以上代碼就可以利用配置文件來啓動一個 Spring 容器了,請使用 maven 的小夥伴直接在 dependencies 中加上以下依賴即可,我比較反對那些不知道要添加什麼依賴,然後把 Spring 的所有相關的東西都加進來的方式。
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.3.11.RELEASE</version>
</dependency>
spring-context 會自動將 spring-core、spring-beans、spring-aop、spring-expression 這幾個基礎 jar 包帶進來。
Spring 是漸進式的工具,並不具有很強的侵入性,它的模塊也劃分得很合理,即使你的應用不是 web 應用,或者之前完全沒有使用到 Spring,而你就想用 Spring 的依賴注入這個功能,其實完全是可以的,它的引入不會對其他的組件產生衝突。ApplicationContext context = new ClassPathXmlApplicationContext(...)
其實很好理解,從名字上就可以猜出一二,就是在 ClassPath 中尋找 xml 配置文件,根據 xml 文件內容來構建 ApplicationContext。當然,除了 ClassPathXmlApplicationContext 以外,我們也還有其他構建 ApplicationContext 的方案可供選擇,我們先來看看大體的繼承結構是怎麼樣的:
我們可以看到,ClassPathXmlApplicationContext兜兜轉轉了好久纔到 ApplicationContext 接口。同樣的,也可以使用 FileSystemXmlApplicationContext 和 AnnotationConfigApplicationContext 這兩個類來初始化ApplicationContext。 **FileSystemXmlApplicationContext**的構造函數需要一個xml配置文件在系統中的路徑,其他和ClassPathXmlApplicationContext 基本上一樣。 **AnnotationConfigApplicationContext**是基於註解來使用的,它不需要配置文件,採用java配置類和各種註解來配置,是比較簡單的方式,也是大勢所趨吧。 不過本文旨在幫助大家理解整個構建流程,所以決定使用 ClassPathXmlApplicationContext 進行分析。我們先來一個簡單的例子來看看怎麼實例化 ApplicationContext。 首先,定義一個接口:讀者可以大致看一下類名,源碼分析的時候不至於找不着看哪個類,因爲 Spring 爲了適應各種使用場景,提供的各個接口都可能有很多的實現類。對於我們來說,就是揪着一個完整的分支看完。當然,閱讀本文的時候讀者也不必太擔心,每個代碼塊分析的時候,我都會告訴讀者我們在說哪個類第幾行。
public interface MessageService {
String getMessage();
}
定義接口實現類:
public class MessageServiceImpl implements MessageService {
public String getMessage() {
return "hello world";
}
}
接下來,我們在 resources 目錄新建一個配置文件,文件名隨意,通常叫 application.xml 或 application-xxx.xml就可以了:
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">
<bean id="messageService" class="com.javadoop.example.MessageServiceImpl"/>
</beans>
這樣,我們就可以跑起來了:
public class App {
public static void main(String[] args) {
// 用我們的配置文件來啓動一個 ApplicationContext
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");
System.out.println("context 啓動成功");
// 從 context 中取出我們的 Bean,而不是用 new MessageServiceImpl() 這種方式
MessageService messageService = context.getBean(MessageService.class);
// 這句將輸出: hello world
System.out.println(messageService.getMessage());
}
}
以上例子很簡單,不過也夠引出本文的主題了,就是怎麼樣通過配置文件來啓動 Spring 的 ApplicationContext。也就是我們今天要分析的 IOC 的核心了。ApplicationContext 啓動過程中,會負責創建實例 Bean,往各個 Bean 中注入依賴等。
BeanFactory 簡介
初學者可別以爲我之前說那麼多和 BeanFactory 無關,前面說的 ApplicationContext 其實就是一個 BeanFactory。我們來看下和 BeanFactory 接口相關的主要的繼承結構:
繼承圖略複雜。ApplicationContext 往下的繼承結構前面一張圖說過了,這裏就不重複了。這張圖呢,背下來肯定是不需要的,有幾個重點和大家說明下就好。
- ApplicationContext 繼承了 ListableBeanFactory,這個 Listable 的意思就是,通過這個接口,我們可以獲取多個 Bean,最頂層 BeanFactory 接口的方法都是獲取單個 Bean 的。
- ApplicationContext 繼承了 HierarchicalBeanFactory,Hierarchical 單詞本身已經能說明問題了,也就是說我們可以在應用中起多個 BeanFactory,然後可以將各個 BeanFactory 設置爲父子關係。
- AutowireCapableBeanFactory 這個名字中的 Autowire 大家都非常熟悉,它就是用來自動裝配 Bean 用的,但是仔細看上圖,ApplicationContext 並沒有繼承它,不過不用擔心,不使用繼承,不代表不可以使用組合,如果你看到 ApplicationContext 接口定義中的最後一個方法 getAutowireCapableBeanFactory() 就知道了。
- ConfigurableListableBeanFactory 也是一個特殊的接口,看圖,特殊之處在於它繼承了第二層所有的三個接口,而 ApplicationContext 沒有。這點之後會用到。
- 請先不用花時間在其他的接口和類上,先理解我說的這幾點就可以了。
然後,請讀者打開編輯器,翻一下 BeanFactory、ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory、ApplicationContext 這幾個接口的代碼,大概看一下各個接口中的方法,大家心裏要有底,限於篇幅,我就不貼代碼介紹了。
啓動過程分析
下面將會是冗長的代碼分析,第一步,我們肯定要從 ClassPathXmlApplicationContext 的構造方法說起。
public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {
private Resource[] configResources;
// 如果已經有 ApplicationContext 並需要配置成父子關係,那麼調用這個構造方法
public ClassPathXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
...
public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
throws BeansException {
super(parent);
// 根據提供的路徑,處理成配置文件數組(以分號、逗號、空格、tab、換行符分割)
setConfigLocations(configLocations);
if (refresh) {
refresh(); // 核心方法
}
}
...
}
接下來,就是 refresh(),這裏簡單說下爲什麼是 refresh(),而不是 init() 這種名字的方法。因爲 ApplicationContext 建立起來以後,其實我們是可以通過調用 refresh() 這個方法重建的,這樣會將原來的 ApplicationContext 銷燬,然後再重新執行一次初始化操作。
往下看,refresh() 方法裏面調用了那麼多方法,就知道肯定不簡單了,請讀者先看個大概,細節之後會詳細說。
@Override
public void refresh() throws BeansException, IllegalStateException {
// 來個鎖,不然 refresh() 還沒結束,你又來個啓動或銷燬容器的操作,那不就亂套了嘛
synchronized (this.startupShutdownMonitor) {
// 準備工作,記錄下容器的啓動時間、標記“已啓動”狀態、處理配置文件中的佔位符
//這裏會重新設置容器啓動時間和啓動標誌字段
prepareRefresh();
// 這步比較關鍵,這步完成後,配置文件就會解析成一個個 Bean 定義,註冊到 BeanFactory 中,
// 當然,這裏說的 Bean 還沒有初始化,只是配置信息都提取出來了,
// 註冊也只是將這些信息都保存到了註冊中心(說到底核心是一個 beanName-> beanDefinition 的 map)
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 設置 BeanFactory 的類加載器,添加幾個 BeanPostProcessor,手動註冊幾個特殊的 bean
// 這塊待會會展開說
/**
* 這個方法主要是爲後面實例化bean做一些設置
* 1.設置ClassLoader
* 2.addPropertyEditorRegistrar,設置用戶定義的propertyEditor註冊器
* 3.addBeanPostProcessor,設置ApplicationContextAwareProcessor, 處理ApplicationContextAware實現接口的Bean。
* 4.ignoreDependencyInterface,設置不解析某些接口的依賴關係
* 5.registerResolvableDependency,設置特殊接口和bean的綁定關係
*/
prepareBeanFactory(beanFactory);
try {
// 【這裏需要知道 BeanFactoryPostProcessor 這個知識點,Bean 如果實現了此接口,
// 那麼在容器初始化以後,Spring 會負責調用裏面的 postProcessBeanFactory 方法。】
// 這裏是提供給子類的擴展點,到這裏的時候,所有的 Bean 都加載、註冊完成了,但是都還沒有初始化
// 具體的子類可以在這步的時候添加一些特殊的 BeanFactoryPostProcessor 的實現類或做點什麼事
postProcessBeanFactory(beanFactory);
// 調用 BeanFactoryPostProcessor 各個實現類的 postProcessBeanFactory(factory) 方法
invokeBeanFactoryPostProcessors(beanFactory);
// 註冊 BeanPostProcessor 的實現類,注意看和 BeanFactoryPostProcessor 的區別
// 此接口兩個方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
// 兩個方法分別在 Bean 初始化之前和初始化之後得到執行。注意,到這裏 Bean 還沒初始化
registerBeanPostProcessors(beanFactory);
// 初始化當前 ApplicationContext 的 MessageSource,國際化這裏就不展開說了,不然沒完沒了了
initMessageSource();
// 初始化當前 ApplicationContext 的事件廣播器,這裏也不展開了
initApplicationEventMulticaster();
// 從方法名就可以知道,典型的模板方法(鉤子方法),
// 具體的子類可以在這裏初始化一些特殊的 Bean(在初始化 singleton beans 之前)
onRefresh();
// 註冊事件監聽器,監聽器需要實現 ApplicationListener 接口。這也不是我們的重點,過
registerListeners();
// 重點,重點,重點
// 初始化所有的 singleton beans
//(lazy-init 的除外)
finishBeanFactoryInitialization(beanFactory);
// 最後,廣播事件,ApplicationContext 初始化完成
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
// 銷燬已經初始化的 singleton 的 Beans,以免有些 bean 會一直佔用資源
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// 把異常往外拋
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
下面,我們開始一步步來肢解這個 refresh() 方法。
創建 Bean 容器前的準備工作
這個比較簡單,直接看代碼中的幾個註釋即可。
protected void prepareRefresh() {
// 記錄啓動時間,
// 將 active 屬性設置爲 true,closed 屬性設置爲 false,它們都是 AtomicBoolean 類型
this.startupDate = System.currentTimeMillis();
this.closed.set(false);
this.active.set(true);
if (logger.isInfoEnabled()) {
logger.info("Refreshing " + this);
}
// Initialize any placeholder property sources in the context environment
initPropertySources();
// 校驗 xml 配置文件
getEnvironment().validateRequiredProperties();
this.earlyApplicationEvents = new LinkedHashSet<ApplicationEvent>();
}
創建 Bean 容器,加載並註冊 Bean
注意,這個方法是全文最重要的部分之一,這裏將會初始化 BeanFactory、加載 Bean、註冊 Bean 等等。當然,這步結束後,Bean 並沒有完成初始化。
// AbstractApplicationContext.java
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
// 關閉舊的 BeanFactory (如果有),創建新的 BeanFactory,加載 Bean 定義、註冊 Bean 等等
refreshBeanFactory();
// 返回剛剛創建的 BeanFactory
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (logger.isDebugEnabled()) {
logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}
// AbstractRefreshableApplicationContext.java 120
@Override
protected final void refreshBeanFactory() throws BeansException {
// 如果 ApplicationContext 中已經加載過 BeanFactory 了,銷燬所有 Bean,關閉 BeanFactory
// 注意,應用中 BeanFactory 本來就是可以多個的,這裏可不是說應用全局是否有 BeanFactory,而是當前
// ApplicationContext 是否有 BeanFactory
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
// 初始化一個 DefaultListableBeanFactory,爲什麼用這個,我們馬上說。
DefaultListableBeanFactory beanFactory = createBeanFactory();
// 用於 BeanFactory 的序列化,我想不部分人應該都用不到
beanFactory.setSerializationId(getId());
// 下面這兩個方法很重要,別跟丟了,具體細節之後說
// 設置 BeanFactory 的兩個配置屬性:是否允許 Bean 覆蓋、是否允許循環引用
customizeBeanFactory(beanFactory);
// 加載 Bean 到 BeanFactory 中
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
看到這裏的時候,我覺得讀者就應該站在高處看 ApplicationContext 了,ApplicationContext 繼承自 BeanFactory,但是它不應該被理解爲 BeanFactory 的實現類,而是說其內部持有一個實例化的 BeanFactory(DefaultListableBeanFactory)。以後所有的 BeanFactory 相關的操作其實是給這個實例來處理的。
我們說說爲什麼選擇實例化 DefaultListableBeanFactory ?前面我們說了有個很重要的接口 ConfigurableListableBeanFactory,它實現了 BeanFactory 下面一層的所有三個接口,我把之前的繼承圖再拿過來大家再仔細看一下:
我們可以看到 ConfigurableListableBeanFactory 只有一個實現類DefaultListableBeanFactory,而且實現類 DefaultListableBeanFactory 還通過實現右邊的 AbstractAutowireCapableBeanFactory 通吃了右路。所以結論就是,最底下這個傢伙 DefaultListableBeanFactory 基本上是最牛的 BeanFactory 了,這也是爲什麼這邊會使用這個類來實例化的原因.
在繼續往下之前,我們需要先了解 BeanDefinition。我們說 BeanFactory 是 Bean 容器,那麼 Bean 又是什麼呢?
這裏的 BeanDefinition 就是我們所說的 Spring 的 Bean,我們自己定義的各個 Bean 其實會轉換成一個個 BeanDefinition 存在於 Spring 的 BeanFactory 中。
所以,如果有人問你 Bean 是什麼的時候,你要知道 Bean 在代碼層面上是 BeanDefinition 的實例。
BeanDefinition 中保存了我們的 Bean 信息,比如這個 Bean 指向的是哪個類、是否是單例的、是否懶加載、這個 Bean 依賴了哪些 Bean 等等。
BeanDefinition 接口定義
我們來看下 BeanDefinition 的接口定義:
public interface BeanDefinition extends AttributeAccessor, BeanMetadataElement {
// 我們可以看到,默認只提供 sington 和 prototype 兩種,
// 很多讀者都知道還有 request, session, globalSession, application, websocket 這幾種,
// 不過,它們屬於基於 web 的擴展。
String SCOPE_SINGLETON = ConfigurableBeanFactory.SCOPE_SINGLETON;
String SCOPE_PROTOTYPE = ConfigurableBeanFactory.SCOPE_PROTOTYPE;
// 比較不重要,直接跳過吧
int ROLE_APPLICATION = 0;
int ROLE_SUPPORT = 1;
int ROLE_INFRASTRUCTURE = 2;
// 設置父 Bean,這裏涉及到 bean 繼承,不是 java 繼承。請參見附錄介紹
void setParentName(String parentName);
// 獲取父 Bean
String getParentName();
// 設置 Bean 的類名稱
void setBeanClassName(String beanClassName);
// 獲取 Bean 的類名稱
String getBeanClassName();
// 設置 bean 的 scope
void setScope(String scope);
String getScope();
// 設置是否懶加載
void setLazyInit(boolean lazyInit);
boolean isLazyInit();
// 設置該 Bean 依賴的所有的 Bean,注意,這裏的依賴不是指屬性依賴(如 @Autowire 標記的),
// 是 depends-on="" 屬性設置的值。
void setDependsOn(String... dependsOn);
// 返回該 Bean 的所有依賴
String[] getDependsOn();
// 設置該 Bean 是否可以注入到其他 Bean 中,只對根據類型注入有效,
// 如果根據名稱注入,即使這邊設置了 false,也是可以的
void setAutowireCandidate(boolean autowireCandidate);
// 該 Bean 是否可以注入到其他 Bean 中
boolean isAutowireCandidate();
// 主要的。同一接口的多個實現,如果不指定名字的話,Spring 會優先選擇設置 primary 爲 true 的 bean
void setPrimary(boolean primary);
// 是否是 primary 的
boolean isPrimary();
// 如果該 Bean 採用工廠方法生成,指定工廠名稱。對工廠不熟悉的讀者,請參加附錄
void setFactoryBeanName(String factoryBeanName);
// 獲取工廠名稱
String getFactoryBeanName();
// 指定工廠類中的 工廠方法名稱
void setFactoryMethodName(String factoryMethodName);
// 獲取工廠類中的 工廠方法名稱
String getFactoryMethodName();
// 構造器參數
ConstructorArgumentValues getConstructorArgumentValues();
// Bean 中的屬性值,後面給 bean 注入屬性值的時候會說到
MutablePropertyValues getPropertyValues();
// 是否 singleton
boolean isSingleton();
// 是否 prototype
boolean isPrototype();
// 如果這個 Bean 原生是抽象類,那麼不能實例化
boolean isAbstract();
int getRole();
String getDescription();
String getResourceDescription();
BeanDefinition getOriginatingBeanDefinition();
}
這個 BeanDefinition 其實已經包含很多的信息了,暫時不清楚所有的方法對應什麼東西沒關係,希望看完本文後讀者可以徹底搞清楚裏面的所有東西。 這裏接口雖然那麼多,但是沒有類似 getInstance() 這種方法來獲取我們定義的類的實例,真正的我們定義的類生成的實例到哪裏去了呢?彆着急,這個要很後面才能講到。
有了 BeanDefinition 的概念以後,我們再往下看 refreshBeanFactory() 方法中的剩餘部分:
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
customizeBeanFactory(beanFactory)
customizeBeanFactory(beanFactory) 比較簡單,就是配置是否允許 BeanDefinition 覆蓋、是否允許循環引用。
protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
if (this.allowBeanDefinitionOverriding != null) {
// 是否允許 Bean 定義覆蓋
beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
}
if (this.allowCircularReferences != null) {
// 是否允許 Bean 間的循環依賴
beanFactory.setAllowCircularReferences(this.allowCircularReferences);
}
}
BeanDefinition 的覆蓋問題大家也許會碰到,就是在配置文件中定義 bean 時使用了相同的 id 或 name,默認情況下,allowBeanDefinitionOverriding 屬性爲 null,如果在同一配置文件中重複了,會拋錯,但是如果不是同一配置文件中,會發生覆蓋。
循環引用也很好理解:A 依賴 B,而 B 依賴 A。或 A 依賴 B,B 依賴 C,而 C 依賴 A。
默認情況下,Spring 允許循環依賴,當然如果你在 A 的構造方法中依賴 B,在 B 的構造方法中依賴 A 是不行的。
至於這兩個屬性怎麼配置?我在附錄中進行了介紹,尤其對於覆蓋問題,很多人都希望禁止出現 Bean 覆蓋,可是 Spring 默認是不同文件的時候可以覆蓋的。
之後的源碼中還會出現這兩個屬性,讀者有個印象就可以了。
加載 Bean: loadBeanDefinitions(beanFactory)
接下來是最重要的 loadBeanDefinitions(beanFactory) 方法了,這個方法將根據配置,加載各個 Bean,然後放到 BeanFactory 中。
讀取配置的操作在 XmlBeanDefinitionReader 中,其負責加載配置、解析。
// AbstractXmlApplicationContext.java 80
/** 我們可以看到,此方法將通過一個 XmlBeanDefinitionReader 實例來加載各個 Bean。*/
@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// 給這個 BeanFactory 實例化一個 XmlBeanDefinitionReader
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// Configure the bean definition reader with this context's
// resource loading environment.
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 初始化 BeanDefinitionReader,其實這個是提供給子類覆寫的,
// 我看了一下,沒有類覆寫這個方法,我們姑且當做不重要吧
initBeanDefinitionReader(beanDefinitionReader);
// 重點來了,繼續往下
loadBeanDefinitions(beanDefinitionReader);
}
現在還在這個類中,接下來用剛剛初始化的 Reader 開始來加載 xml 配置,這塊代碼讀者可以選擇性跳過,不是很重要。也就是說,下面這個代碼塊,讀者可以很輕鬆地略過。
// AbstractXmlApplicationContext.java 120
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = getConfigResources();
if (configResources != null) {
// 往下看
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = getConfigLocations();
if (configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}
// 上面雖然有兩個分支,不過第二個分支很快通過解析路徑轉換爲 Resource 以後也會進到這裏
@Override
public int loadBeanDefinitions(Resource... resources) throws BeanDefinitionStoreException {
Assert.notNull(resources, "Resource array must not be null");
int counter = 0;
// 注意這裏是個 for 循環,也就是每個文件是一個 resource
for (Resource resource : resources) {
// 繼續往下看
counter += loadBeanDefinitions(resource);
}
return counter;
}
// XmlBeanDefinitionReader 303
@Override
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
return loadBeanDefinitions(new EncodedResource(resource));
}
// XmlBeanDefinitionReader 314
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
Assert.notNull(encodedResource, "EncodedResource must not be null");
if (logger.isInfoEnabled()) {
logger.info("Loading XML bean definitions from " + encodedResource.getResource());
}
// 用一個 ThreadLocal 來存放所有的配置文件資源
Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
if (currentResources == null) {
currentResources = new HashSet<EncodedResource>(4);
this.resourcesCurrentlyBeingLoaded.set(currentResources);
}
if (!currentResources.add(encodedResource)) {
throw new BeanDefinitionStoreException(
"Detected cyclic loading of " + encodedResource + " - check your import definitions!");
}
try {
InputStream inputStream = encodedResource.getResource().getInputStream();
try {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
// 核心部分
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
inputStream.close();
}
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.getResource(), ex);
}
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
// 還在這個文件中,第 388 行
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
// 這裏就不看了
Document doc = doLoadDocument(inputSource, resource);
// 繼續
return registerBeanDefinitions(doc, resource);
}
catch (...
}
// 還在這個文件中,第 505 行
// 返回從當前配置文件加載了多少數量的 Bean
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
int countBefore = getRegistry().getBeanDefinitionCount();
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
// DefaultBeanDefinitionDocumentReader 90
@Override
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
this.readerContext = readerContext;
logger.debug("Loading bean definitions");
Element root = doc.getDocumentElement();
doRegisterBeanDefinitions(root);
}
doRegisterBeanDefinitions
// DefaultBeanDefinitionDocumentReader 116
protected void doRegisterBeanDefinitions(Element root) {
// 我們看名字就知道,BeanDefinitionParserDelegate 必定是一個重要的類,它負責解析 Bean 定義,
// 這裏爲什麼要定義一個 parent? 看到後面就知道了,是遞歸問題,
// 因爲 <beans /> 內部是可以定義 <beans /> 的,所以這個方法的 root 其實不一定就是 xml 的根節點,也可以是嵌套在裏面的 <beans /> 節點,從源碼分析的角度,我們當做根節點就好了
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(getReaderContext(), root, parent);
if (this.delegate.isDefaultNamespace(root)) {
// 這塊說的是根節點 <beans ... profile="dev" /> 中的 profile 是否是當前環境需要的,
// 如果當前環境配置的 profile 不包含此 profile,那就直接 return 了,不對此 <beans /> 解析
// 不熟悉 profile 爲何物,不熟悉怎麼配置 profile 讀者的請移步附錄區
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
if (StringUtils.hasText(profileSpec)) {
String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
if (logger.isInfoEnabled()) {
logger.info("Skipped XML bean definition file due to specified profiles [" + profileSpec +
"] not matching: " + getReaderContext().getResource());
}
return;
}
}
}
preProcessXml(root); // 鉤子
parseBeanDefinitions(root, this.delegate);
postProcessXml(root); // 鉤子
this.delegate = parent;
}
preProcessXml(root) 和 postProcessXml(root) 是給子類用的鉤子方法,鑑於沒有被使用到,也不是我們的重點,我們直接跳過。
這裏涉及到了 profile 的問題,對於不瞭解的讀者,我在附錄中對 profile 做了簡單的解釋,讀者可以參考一下。
接下來,看核心解析方法 parseBeanDefinitions(root, this.delegate) :
// default namespace 涉及到的就四個標籤 <import />、<alias />、<bean /> 和 <beans />,
// 其他的屬於 custom 的
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
if (delegate.isDefaultNamespace(ele)) {
parseDefaultElement(ele, delegate);
}
else {
delegate.parseCustomElement(ele);
}
}
}
}
else {
delegate.parseCustomElement(root);
}
}
從上面的代碼,我們可以看到,對於每個配置來說,分別進入到 parseDefaultElement(ele, delegate); 和 delegate.parseCustomElement(ele); 這兩個分支了。
parseDefaultElement(ele, delegate) 代表解析的節點是 、、、 這幾個。
這個 BeanDefinition 這裏的四個標籤之所以是 default 的,是因爲它們是處於這個 namespace 下定義的:http://www.springframework.org/schema/beans 又到初學者科普時間,不熟悉 namespace 的讀者請看下面貼出來的 xml,這裏的第二行 xmlns 就是咯。
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd"
default-autowire="byName">
而對於其他的標籤,將進入到 delegate.parseCustomElement(element) 這個分支。如我們經常會使用到的<mvc />
、<task />
、<context />
、<aop />
等。
這些屬於擴展,如果需要使用上面這些 ”非 default“ 標籤,那麼上面的 xml 頭部的地方也要引入相應的 namespace 和 .xsd 文件的路徑,如下所示。同時代碼中需要提供相應的 parser 來解析,如 MvcNamespaceHandler、TaskNamespaceHandler、ContextNamespaceHandler、AopNamespaceHandler 等。
假如讀者想分析 <context:property-placeholder location="classpath:xx.properties" />
的實現原理,就應該到 ContextNamespaceHandler 中找答案。
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd
"
default-autowire="byName">
回過神來,看看處理 default 標籤的方法:
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
// 處理 <import /> 標籤
importBeanDefinitionResource(ele);
}
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
// 處理 <alias /> 標籤定義
// <alias name="fromName" alias="toName"/>
processAliasRegistration(ele);
}
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
// 處理 <bean /> 標籤定義,這也算是我們的重點吧
processBeanDefinition(ele, delegate);
}
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// 如果碰到的是嵌套的 <beans /> 標籤,需要遞歸
doRegisterBeanDefinitions(ele);
}
}
如果每個標籤都說,那我不吐血,你們都要吐血了。我們挑我們的重點 標籤出來說。
processBeanDefinition
下面是 processBeanDefinition 解析 標籤:
// DefaultBeanDefinitionDocumentReader 298
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// 將 <bean /> 節點中的信息提取出來,然後封裝到一個 BeanDefinitionHolder 中,細節往下看
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
// 下面的幾行先不要看,跳過先,跳過先,跳過先,後面會繼續說的
if (bdHolder != null) {
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// Register the final decorated instance.
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// Send registration event.
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
繼續往下看怎麼解析之前,我們先看下 標籤中可以定義哪些屬性:
Property | desc |
---|---|
class | 類的全限定名 |
name | 可指定 id、name(用逗號、分號、空格分隔) |
scope | 作用域 |
constructor arguments | 指定構造參數 |
properties | 設置屬性的值 |
autowiring mode | no(默認值)、byName、byType、 constructor |
lazy-initialization mode | 是否懶加載(如果被非懶加載的bean依賴了那麼其實也就不能懶加載了) |
initialization method | bean 屬性設置完成後,會調用這個方法 |
destruction method | bean 銷燬後的回調方法 |
上面表格中的內容我想大家都非常熟悉吧,如果不熟悉,那就是你不夠了解 Spring 的配置了。簡單地說就是像下面這樣子:
<bean id="exampleBean" name="name1, name2, name3" class="com.javadoop.ExampleBean"
scope="singleton" lazy-init="true" init-method="init" destroy-method="cleanup">
<!-- 可以用下面三種形式指定構造參數 -->
<constructor-arg type="int" value="7500000"/>
<constructor-arg name="years" value="7500000"/>
<constructor-arg index="0" value="7500000"/>
<!-- property 的幾種情況 -->
<property name="beanOne">
<ref bean="anotherExampleBean"/>
</property>
<property name="beanTwo" ref="yetAnotherBean"/>
<property name="integerProperty" value="1"/>
</bean>
當然,除了上面舉例出來的這些,還有 factory-bean
、factory-method
、<lockup-method />
、<replaced-method />
、<meta />
、<qualifier />
這幾個,大家是不是熟悉呢?
有了以上這些知識以後,我們再繼續往裏看怎麼解析 bean 元素,是怎麼轉換到 BeanDefinitionHolder 的。
// BeanDefinitionParserDelegate 428
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
return parseBeanDefinitionElement(ele, null);
}
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {
String id = ele.getAttribute(ID_ATTRIBUTE);
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
List<String> aliases = new ArrayList<String>();
// 將 name 屬性的定義按照 ”逗號、分號、空格“ 切分,形成一個別名列表數組,
// 當然,如果你不定義的話,就是空的了
// 我在附錄中簡單介紹了一下 id 和 name 的配置,大家可以看一眼,有個20秒就可以了
if (StringUtils.hasLength(nameAttr)) {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
}
String beanName = id;
// 如果沒有指定id, 那麼用別名列表的第一個名字作爲beanName
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove(0);
if (logger.isDebugEnabled()) {
logger.debug("No XML 'id' specified - using '" + beanName +
"' as bean name and " + aliases + " as aliases");
}
}
if (containingBean == null) {
checkNameUniqueness(beanName, aliases, ele);
}
// 根據 <bean ...>...</bean> 中的配置創建 BeanDefinition,然後把配置中的信息都設置到實例中,
// 細節後面再說
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
// 到這裏,整個 <bean /> 標籤就算解析結束了,一個 BeanDefinition 就形成了。
if (beanDefinition != null) {
// 如果都沒有設置 id 和 name,那麼此時的 beanName 就會爲 null,進入下面這塊代碼產生
// 如果讀者不感興趣的話,我覺得不需要關心這塊代碼,對本文源碼分析來說,這些東西不重要
if (!StringUtils.hasText(beanName)) {
try {
if (containingBean != null) {// 按照我們的思路,這裏 containingBean 是 null 的
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
}
else {
// 如果我們不定義 id 和 name,那麼我們引言裏的那個例子:
// 1. beanName 爲:com.javadoop.example.MessageServiceImpl#0
// 2. beanClassName 爲:com.javadoop.example.MessageServiceImpl
beanName = this.readerContext.generateBeanName(beanDefinition);
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
!this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
// 把 beanClassName 設置爲 Bean 的別名
aliases.add(beanClassName);
}
}
if (logger.isDebugEnabled()) {
logger.debug("Neither XML 'id' nor 'name' specified - " +
"using generated bean name [" + beanName + "]");
}
}
catch (Exception ex) {
error(ex.getMessage(), ele);
return null;
}
}
String[] aliasesArray = StringUtils.toStringArray(aliases);
// 返回 BeanDefinitionHolder
return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
}
return null;
}
看看怎麼根據配置創建 BeanDefinition:
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, BeanDefinition containingBean) {
this.parseState.push(new BeanEntry(beanName));
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
}
try {
String parent = null;
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
}
// 創建 BeanDefinition,然後設置類信息而已,很簡單,就不貼代碼了
AbstractBeanDefinition bd = createBeanDefinition(className, parent);
// 設置 BeanDefinition 的一堆屬性,這些屬性定義在 AbstractBeanDefinition 中
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
/**
* 下面的一堆是解析 <bean>......</bean> 內部的子元素,
* 解析出來以後的信息都放到 bd 的屬性中
*/
// 解析 <meta />
parseMetaElements(ele, bd);
// 解析 <lookup-method />
parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
// 解析 <replaced-method />
parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
// 解析 <constructor-arg />
parseConstructorArgElements(ele, bd);
// 解析 <property />
parsePropertyElements(ele, bd);
// 解析 <qualifier />
parseQualifierElements(ele, bd);
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele));
return bd;
}
catch (ClassNotFoundException ex) {
error("Bean class [" + className + "] not found", ele, ex);
}
catch (NoClassDefFoundError err) {
error("Class that bean class [" + className + "] depends on not found", ele, err);
}
catch (Throwable ex) {
error("Unexpected failure during bean definition parsing", ele, ex);
}
finally {
this.parseState.pop();
}
return null;
}
到這裏,我們已經完成了根據 配置創建了一個 BeanDefinitionHolder 實例。注意,是一個。
我們回到解析 的入口方法:
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// 將 <bean /> 節點轉換爲 BeanDefinitionHolder,就是上面說的一堆
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
// 如果有自定義屬性的話,進行相應的解析,先忽略
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// 我們把這步叫做 註冊Bean 吧
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// 註冊完成後,發送事件,本文不展開說這個
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
大家再仔細看一下這塊吧,我們後面就不回來說這個了。這裏已經根據一個 標籤產生了一個 BeanDefinitionHolder 的實例,這個實例裏面也就是一個 BeanDefinition 的實例和它的 beanName、aliases 這三個信息,注意,我們的關注點始終在 BeanDefinition 上:
public class BeanDefinitionHolder implements BeanMetadataElement {
private final BeanDefinition beanDefinition;
private final String beanName;
private final String[] aliases;
...
然後我們準備註冊這個 BeanDefinition,最後,把這個註冊事件發送出去。
下面,我們開始說註冊 Bean 吧。
註冊 Bean
// BeanDefinitionReaderUtils 143
public static void registerBeanDefinition(
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
throws BeanDefinitionStoreException {
String beanName = definitionHolder.getBeanName();
// 註冊這個 Bean
registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());
// 如果還有別名的話,也要根據別名統統註冊一遍,不然根據別名就找不到 Bean 了,這我們就不開心了
String[] aliases = definitionHolder.getAliases();
if (aliases != null) {
for (String alias : aliases) {
// alias -> beanName 保存它們的別名信息,這個很簡單,用一個 map 保存一下就可以了,
// 獲取的時候,會先將 alias 轉換爲 beanName,然後再查找
registry.registerAlias(beanName, alias);
}
}
}
別名註冊的放一邊,畢竟它很簡單,我們看看怎麼註冊 Bean。
// DefaultListableBeanFactory 793
@Override
public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
throws BeanDefinitionStoreException {
Assert.hasText(beanName, "Bean name must not be empty");
Assert.notNull(beanDefinition, "BeanDefinition must not be null");
if (beanDefinition instanceof AbstractBeanDefinition) {
try {
((AbstractBeanDefinition) beanDefinition).validate();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(...);
}
}
// old? 還記得 “允許 bean 覆蓋” 這個配置嗎?allowBeanDefinitionOverriding
BeanDefinition oldBeanDefinition;
// 之後會看到,所有的 Bean 註冊後會放入這個 beanDefinitionMap 中
oldBeanDefinition = this.beanDefinitionMap.get(beanName);
// 處理重複名稱的 Bean 定義的情況
if (oldBeanDefinition != null) {
if (!isAllowBeanDefinitionOverriding()) {
// 如果不允許覆蓋的話,拋異常
throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription()...
}
else if (oldBeanDefinition.getRole() < beanDefinition.getRole()) {
// log...用框架定義的 Bean 覆蓋用戶自定義的 Bean
}
else if (!beanDefinition.equals(oldBeanDefinition)) {
// log...用新的 Bean 覆蓋舊的 Bean
}
else {
// log...用同等的 Bean 覆蓋舊的 Bean,這裏指的是 equals 方法返回 true 的 Bean
}
// 覆蓋
this.beanDefinitionMap.put(beanName, beanDefinition);
}
else {
// 判斷是否已經有其他的 Bean 開始初始化了.
// 注意,"註冊Bean" 這個動作結束,Bean 依然還沒有初始化,我們後面會有大篇幅說初始化過程,
// 在 Spring 容器啓動的最後,會 預初始化 所有的 singleton beans
if (hasBeanCreationStarted()) {
// Cannot modify startup-time collection elements anymore (for stable iteration)
synchronized (this.beanDefinitionMap) {
this.beanDefinitionMap.put(beanName, beanDefinition);
List<String> updatedDefinitions = new ArrayList<String>(this.beanDefinitionNames.size() + 1);
updatedDefinitions.addAll(this.beanDefinitionNames);
updatedDefinitions.add(beanName);
this.beanDefinitionNames = updatedDefinitions;
if (this.manualSingletonNames.contains(beanName)) {
Set<String> updatedSingletons = new LinkedHashSet<String>(this.manualSingletonNames);
updatedSingletons.remove(beanName);
this.manualSingletonNames = updatedSingletons;
}
}
}
else {
// 最正常的應該是進到這裏。
// 將 BeanDefinition 放到這個 map 中,這個 map 保存了所有的 BeanDefinition
this.beanDefinitionMap.put(beanName, beanDefinition);
// 這是個 ArrayList,所以會按照 bean 配置的順序保存每一個註冊的 Bean 的名字
this.beanDefinitionNames.add(beanName);
// 這是個 LinkedHashSet,代表的是手動註冊的 singleton bean,
// 注意這裏是 remove 方法,到這裏的 Bean 當然不是手動註冊的
// 手動指的是通過調用以下方法註冊的 bean :
// registerSingleton(String beanName, Object singletonObject)
// 這不是重點,解釋只是爲了不讓大家疑惑。Spring 會在後面"手動"註冊一些 Bean,如 "environment"、"systemProperties" 等 bean
this.manualSingletonNames.remove(beanName);
}
// 這個不重要,在預初始化的時候會用到,不必管它。
this.frozenBeanDefinitionNames = null;
}
if (oldBeanDefinition != null || containsSingleton(beanName)) {
resetBeanDefinition(beanName);
}
}
總結一下,到這裏已經初始化了 Bean 容器,<bean />
配置也相應的轉換爲了一個個 BeanDefinition,然後註冊了各個 BeanDefinition 到註冊中心,並且發送了註冊事件。
Bean 容器實例化完成後
說到這裏,我們回到 refresh() 方法,我重新貼了一遍代碼,看看我們說到哪了。是的,我們才說完 obtainFreshBeanFactory() 方法。
考慮到篇幅,這裏開始大幅縮減掉沒必要詳細介紹的部分,大家直接看下面的代碼中的註釋就好了。
@Override
public void refresh() throws BeansException, IllegalStateException {
// 來個鎖,不然 refresh() 還沒結束,你又來個啓動或銷燬容器的操作,那不就亂套了嘛
synchronized (this.startupShutdownMonitor) {
// 準備工作,記錄下容器的啓動時間、標記“已啓動”狀態、處理配置文件中的佔位符
prepareRefresh();
// 這步比較關鍵,這步完成後,配置文件就會解析成一個個 Bean 定義,註冊到 BeanFactory 中,
// 當然,這裏說的 Bean 還沒有初始化,只是配置信息都提取出來了,
// 註冊也只是將這些信息都保存到了註冊中心(說到底核心是一個 beanName-> beanDefinition 的 map)
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 設置 BeanFactory 的類加載器,添加幾個 BeanPostProcessor,手動註冊幾個特殊的 bean
// 這塊待會會展開說
prepareBeanFactory(beanFactory);
try {
// 【這裏需要知道 BeanFactoryPostProcessor 這個知識點,Bean 如果實現了此接口,
// 那麼在容器初始化以後,Spring 會負責調用裏面的 postProcessBeanFactory 方法。】
// 這裏是提供給子類的擴展點,到這裏的時候,所有的 Bean 都加載、註冊完成了,但是都還沒有初始化
// 具體的子類可以在這步的時候添加一些特殊的 BeanFactoryPostProcessor 的實現類或做點什麼事
postProcessBeanFactory(beanFactory);
// 調用 BeanFactoryPostProcessor 各個實現類的 postProcessBeanFactory(factory) 方法
invokeBeanFactoryPostProcessors(beanFactory);
// 註冊 BeanPostProcessor 的實現類,注意看和 BeanFactoryPostProcessor 的區別
// 此接口兩個方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
// 兩個方法分別在 Bean 初始化之前和初始化之後得到執行。注意,到這裏 Bean 還沒初始化
registerBeanPostProcessors(beanFactory);
// 初始化當前 ApplicationContext 的 MessageSource,國際化這裏就不展開說了,不然沒完沒了了
initMessageSource();
// 初始化當前 ApplicationContext 的事件廣播器,這裏也不展開了
initApplicationEventMulticaster();
// 從方法名就可以知道,典型的模板方法(鉤子方法),
// 具體的子類可以在這裏初始化一些特殊的 Bean(在初始化 singleton beans 之前)
onRefresh();
// 註冊事件監聽器,監聽器需要實現 ApplicationListener 接口。這也不是我們的重點,過
registerListeners();
// 重點,重點,重點
// 初始化所有的 singleton beans
//(lazy-init 的除外)
finishBeanFactoryInitialization(beanFactory);
// 最後,廣播事件,ApplicationContext 初始化完成
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
// 銷燬已經初始化的 singleton 的 Beans,以免有些 bean 會一直佔用資源
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// 把異常往外拋
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
準備 Bean 容器: prepareBeanFactory(factory)
這裏簡單介紹下 prepareBeanFactory(factory) 方法:
/**
* Configure the factory's standard context characteristics,
* such as the context's ClassLoader and post-processors.
* @param beanFactory the BeanFactory to configure
*/
protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
// 設置 BeanFactory 的類加載器,我們知道 BeanFactory 需要加載類,也就需要類加載器,
// 這裏設置爲當前 ApplicationContext 的類加載器
beanFactory.setBeanClassLoader(getClassLoader());
// 設置 BeanExpressionResolver
beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
//
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
// 添加一個 BeanPostProcessor,這個 processor 比較簡單,
// 實現了 Aware 接口的幾個特殊的 beans 在初始化的時候,這個 processor 負責回調
beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
// 下面幾行的意思就是,如果某個 bean 依賴於以下幾個接口的實現類,在自動裝配的時候忽略它們,
// Spring 會通過其他方式來處理這些依賴。
beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);
/**
* 下面幾行就是爲特殊的幾個 bean 賦值,如果有 bean 依賴了以下幾個,會注入這邊相應的值,
* 之前我們說過,"當前 ApplicationContext 持有一個 BeanFactory",這裏解釋了第一行
* ApplicationContext 繼承了 ResourceLoader、ApplicationEventPublisher、MessageSource
* 所以對於這幾個,可以賦值爲 this,注意 this 是一個 ApplicationContext
* 那這裏怎麼沒看到爲 MessageSource 賦值呢?那是因爲 MessageSource 被註冊成爲了一個普通的 bean
*/
beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
beanFactory.registerResolvableDependency(ResourceLoader.class, this);
beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
beanFactory.registerResolvableDependency(ApplicationContext.class, this);
// 這個 BeanPostProcessor 也很簡單,在 bean 實例化後,如果是 ApplicationListener 的子類,
// 那麼將其添加到 listener 列表中,可以理解成:註冊事件監聽器
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
// Detect a LoadTimeWeaver and prepare for weaving, if found.
// 這裏涉及到特殊的 bean,名爲:loadTimeWeaver,這不是我們的重點,忽略它
if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
// Set a temporary ClassLoader for type matching.
beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
}
/**
* 從下面幾行代碼我們可以知道,Spring 往往很 "智能" 就是因爲它會幫我們默認註冊一些有用的 bean,
* 我們也可以選擇覆蓋
*/
// 如果沒有定義 "environment" 這個 bean,那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
}
// 如果沒有定義 "systemProperties" 這個 bean,那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
}
// 如果沒有定義 "systemEnvironment" 這個 bean,那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
}
}
在上面這塊代碼中,Spring 對一些特殊的 bean 進行了處理,讀者如果暫時還不能消化它們也沒有關係,慢慢往下看。
初始化所有的 singleton beans
我們的重點當然是 finishBeanFactoryInitialization(beanFactory); 這個巨頭了,這裏會負責初始化所有的 singleton beans。
注意,後面的描述中,我都會使用初始化或預初始化來代表這個階段。主要是 Spring 需要在這個階段完成所有的 singleton beans 的實例化。
我們來總結一下,到目前爲止,應該說 BeanFactory 已經創建完成,並且所有的實現了 BeanFactoryPostProcessor 接口的 Bean 都已經初始化並且其中的 postProcessBeanFactory(factory) 方法已經得到執行了。所有實現了 BeanPostProcessor 接口的 Bean 也都完成了初始化。
剩下的就是初始化其他還沒被初始化的 singleton beans 了,我們知道它們是單例的,如果沒有設置懶加載,那麼 Spring 會在接下來初始化所有的 singleton beans。
// AbstractApplicationContext.java 834
// 初始化剩餘的 singleton beans
protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
// 首先,初始化名字爲 conversionService 的 Bean。本着送佛送到西的精神,我在附錄中簡單介紹了一下 ConversionService,因爲這實在太實用了
// 什麼,看代碼這裏沒有初始化 Bean 啊!
// 注意了,初始化的動作包裝在 beanFactory.getBean(...) 中,這裏先不說細節,先往下看吧
if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
beanFactory.setConversionService(
beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
}
if (!beanFactory.hasEmbeddedValueResolver()) {
beanFactory.addEmbeddedValueResolver(new StringValueResolver() {
@Override
public String resolveStringValue(String strVal) {
return getEnvironment().resolvePlaceholders(strVal);
}
});
}
// 先初始化 LoadTimeWeaverAware 類型的 Bean
// 一般用於織入第三方模塊,在 class 文件載入 JVM 的時候動態織入,這裏不展開說
String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
for (String weaverAwareName : weaverAwareNames) {
getBean(weaverAwareName);
}
beanFactory.setTempClassLoader(null);
// 沒什麼別的目的,因爲到這一步的時候,Spring 已經開始預初始化 singleton beans 了,
// 肯定不希望這個時候還出現 bean 定義解析、加載、註冊。
beanFactory.freezeConfiguration();
// 開始初始化剩下的
beanFactory.preInstantiateSingletons();
}
從上面最後一行往裏看,我們又回到 DefaultListableBeanFactory 這個類了,這個類大家應該都不陌生了吧。
preInstantiateSingletons
// DefaultListableBeanFactory 728
@Override
public void preInstantiateSingletons() throws BeansException {
if (this.logger.isDebugEnabled()) {
this.logger.debug("Pre-instantiating singletons in " + this);
}
List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);
// 觸發所有的非懶加載的 singleton beans 的初始化操作
for (String beanName : beanNames) {
// 合併父 Bean 中的配置,注意 <bean id="" class="" parent="" /> 中的 parent,用的不多吧,
// 考慮到這可能會影響大家的理解,我在附錄中解釋了一下 "Bean 繼承",請移步
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
// 非抽象、非懶加載的 singletons。如果配置了 'abstract = true',那是不需要初始化的
if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
// 處理 FactoryBean(讀者如果不熟悉 FactoryBean,請移步附錄區瞭解)
if (isFactoryBean(beanName)) {
// FactoryBean 的話,在 beanName 前面加上 ‘&’ 符號。再調用 getBean,getBean 方法別急
final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX + beanName);
// 判斷當前 FactoryBean 是否是 SmartFactoryBean 的實現,此處忽略,直接跳過
boolean isEagerInit;
if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
isEagerInit = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
@Override
public Boolean run() {
return ((SmartFactoryBean<?>) factory).isEagerInit();
}
}, getAccessControlContext());
}
else {
isEagerInit = (factory instanceof SmartFactoryBean &&
((SmartFactoryBean<?>) factory).isEagerInit());
}
if (isEagerInit) {
getBean(beanName);
}
}
else {
// 對於普通的 Bean,只要調用 getBean(beanName) 這個方法就可以進行初始化了
getBean(beanName);
}
}
}
// 到這裏說明所有的非懶加載的 singleton beans 已經完成了初始化
// 如果我們定義的 bean 是實現了 SmartInitializingSingleton 接口的,那麼在這裏得到回調,忽略
for (String beanName : beanNames) {
Object singletonInstance = getSingleton(beanName);
if (singletonInstance instanceof SmartInitializingSingleton) {
final SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;
if (System.getSecurityManager() != null) {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
smartSingleton.afterSingletonsInstantiated();
return null;
}
}, getAccessControlContext());
}
else {
smartSingleton.afterSingletonsInstantiated();
}
}
}
}
接下來,我們就進入到 getBean(beanName) 方法了,這個方法我們經常用來從 BeanFactory 中獲取一個 Bean,而初始化的過程也封裝到了這個方法裏。
getBean
在繼續前進之前,讀者應該具備 FactoryBean 的知識,如果讀者還不熟悉,請移步附錄部分了解 FactoryBean。
// AbstractBeanFactory 196
@Override
public Object getBean(String name) throws BeansException {
return doGetBean(name, null, null, false);
}
// 我們在剖析初始化 Bean 的過程,但是 getBean 方法我們經常是用來從容器中獲取 Bean 用的,注意切換思路,
// 已經初始化過了就從容器中直接返回,否則就先初始化再返回
@SuppressWarnings("unchecked")
protected <T> T doGetBean(
final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
throws BeansException {
// 獲取一個 “正統的” beanName,處理兩種情況,一個是前面說的 FactoryBean(前面帶 ‘&’),
// 一個是別名問題,因爲這個方法是 getBean,獲取 Bean 用的,你要是傳一個別名進來,是完全可以的
final String beanName = transformedBeanName(name);
// 注意跟着這個,這個是返回值
Object bean;
// 檢查下是不是已經創建過了
Object sharedInstance = getSingleton(beanName);
// 這裏說下 args 唄,雖然看上去一點不重要。前面我們一路進來的時候都是 getBean(beanName),
// 所以 args 其實是 null 的,但是如果 args 不爲空的時候,那麼意味着調用方不是希望獲取 Bean,而是創建 Bean
if (sharedInstance != null && args == null) {
if (logger.isDebugEnabled()) {
if (isSingletonCurrentlyInCreation(beanName)) {
logger.debug("...");
}
else {
logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
}
}
// 下面這個方法:如果是普通 Bean 的話,直接返回 sharedInstance,
// 如果是 FactoryBean 的話,返回它創建的那個實例對象
// (FactoryBean 知識,讀者若不清楚請移步附錄)
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
else {
if (isPrototypeCurrentlyInCreation(beanName)) {
// 當前線程已經創建過了此 beanName 的 prototype 類型的 bean,那麼拋異常
throw new BeanCurrentlyInCreationException(beanName);
}
// 檢查一下這個 BeanDefinition 在容器中是否存在
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
// 如果當前容器不存在這個 BeanDefinition,試試父容器中有沒有
String nameToLookup = originalBeanName(name);
if (args != null) {
// 返回父容器的查詢結果
return (T) parentBeanFactory.getBean(nameToLookup, args);
}
else {
// No args -> delegate to standard getBean method.
return parentBeanFactory.getBean(nameToLookup, requiredType);
}
}
if (!typeCheckOnly) {
// typeCheckOnly 爲 false,將當前 beanName 放入一個 alreadyCreated 的 Set 集合中。
markBeanAsCreated(beanName);
}
/*
* 稍稍總結一下:
* 到這裏的話,要準備創建 Bean 了,對於 singleton 的 Bean 來說,容器中還沒創建過此 Bean;
* 對於 prototype 的 Bean 來說,本來就是要創建一個新的 Bean。
*/
try {
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
// 先初始化依賴的所有 Bean,這個很好理解。
// 注意,這裏的依賴指的是 depends-on 中定義的依賴
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
for (String dep : dependsOn) {
// 檢查是不是有循環依賴,這裏的循環依賴和我們前面說的循環依賴又不一樣,這裏肯定是不允許出現的,不然要亂套了,讀者想一下就知道了
if (isDependent(beanName, dep)) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
}
// 註冊一下依賴關係
registerDependentBean(dep, beanName);
// 先初始化被依賴項
getBean(dep);
}
}
// 創建 singleton 的實例
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
try {
// 執行創建 Bean,詳情後面再說
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
// 創建 prototype 的實例
else if (mbd.isPrototype()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null;
try {
beforePrototypeCreation(beanName);
// 執行創建 Bean
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
// 如果不是 singleton 和 prototype 的話,需要委託給相應的實現類來處理
else {
String scopeName = mbd.getScope();
final Scope scope = this.scopes.get(scopeName);
if (scope == null) {
throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
}
try {
Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
beforePrototypeCreation(beanName);
try {
// 執行創建 Bean
return createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
}
});
bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
}
catch (IllegalStateException ex) {
throw new BeanCreationException(beanName,
"Scope '" + scopeName + "' is not active for the current thread; consider " +
"defining a scoped proxy for this bean if you intend to refer to it from a singleton",
ex);
}
}
}
catch (BeansException ex) {
cleanupAfterBeanCreationFailure(beanName);
throw ex;
}
}
// 最後,檢查一下類型對不對,不對的話就拋異常,對的話就返回了
if (requiredType != null && bean != null && !requiredType.isInstance(bean)) {
try {
return getTypeConverter().convertIfNecessary(bean, requiredType);
}
catch (TypeMismatchException ex) {
if (logger.isDebugEnabled()) {
logger.debug("Failed to convert bean '" + name + "' to required type '" +
ClassUtils.getQualifiedName(requiredType) + "'", ex);
}
throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
}
}
return (T) bean;
}
大家應該也猜到了,接下來當然是分析 createBean 方法:
protected abstract Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException;
第三個參數 args 數組代表創建實例需要的參數,不就是給構造方法用的參數,或者是工廠 Bean 的參數嘛,不過要注意,在我們的初始化階段,args 是 null。
這回我們要到一個新的類了 AbstractAutowireCapableBeanFactory,看類名,AutowireCapable?類名是不是也說明了點問題了。
主要是爲了以下場景,採用 @Autowired 註解注入屬性值:
public class MessageServiceImpl implements MessageService {
@Autowired
private UserService userService;
public String getMessage() {
return userService.getMessage();
}
}
<bean id="messageService" class="com.javadoop.example.MessageServiceImpl" />
好了,讀者要知道這麼回事就可以了,繼續向前。
// AbstractAutowireCapableBeanFactory 447
/**
* Central method of this class: creates a bean instance,
* populates the bean instance, applies post-processors, etc.
* @see #doCreateBean
*/
@Override
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
if (logger.isDebugEnabled()) {
logger.debug("Creating instance of bean '" + beanName + "'");
}
RootBeanDefinition mbdToUse = mbd;
// 確保 BeanDefinition 中的 Class 被加載
Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
mbdToUse = new RootBeanDefinition(mbd);
mbdToUse.setBeanClass(resolvedClass);
}
// 準備方法覆寫,這裏又涉及到一個概念:MethodOverrides,它來自於 bean 定義中的 <lookup-method />
// 和 <replaced-method />,如果讀者感興趣,回到 bean 解析的地方看看對這兩個標籤的解析。
// 我在附錄中也對這兩個標籤的相關知識點進行了介紹,讀者可以移步去看看
try {
mbdToUse.prepareMethodOverrides();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
beanName, "Validation of method overrides failed", ex);
}
try {
// 讓 BeanPostProcessor 在這一步有機會返回代理,而不是 bean 實例,
// 要徹底瞭解清楚這個,需要去看 InstantiationAwareBeanPostProcessor 接口,這裏就不展開說了
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
if (bean != null) {
return bean;
}
}
catch (Throwable ex) {
throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
"BeanPostProcessor before instantiation of bean failed", ex);
}
// 重頭戲,創建 bean
Object beanInstance = doCreateBean(beanName, mbdToUse, args);
if (logger.isDebugEnabled()) {
logger.debug("Finished creating instance of bean '" + beanName + "'");
}
return beanInstance;
}
創建 Bean
往裏看 doCreateBean 這個方法:
/**
* Actually create the specified bean. Pre-creation processing has already happened
* at this point, e.g. checking {@code postProcessBeforeInstantiation} callbacks.
* <p>Differentiates between default bean instantiation, use of a
* factory method, and autowiring a constructor.
* @param beanName the name of the bean
* @param mbd the merged bean definition for the bean
* @param args explicit arguments to use for constructor or factory method invocation
* @return a new instance of the bean
* @throws BeanCreationException if the bean could not be created
* @see #instantiateBean
* @see #instantiateUsingFactoryMethod
* @see #autowireConstructor
*/
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
throws BeanCreationException {
// Instantiate the bean.
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 說明不是 FactoryBean,這裏實例化 Bean,這裏非常關鍵,細節之後再說
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
// 這個就是 Bean 裏面的 我們定義的類 的實例,很多地方我描述成 "bean 實例"
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
// 類型
Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
mbd.resolvedTargetType = beanType;
// 建議跳過吧,涉及接口:MergedBeanDefinitionPostProcessor
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
try {
// MergedBeanDefinitionPostProcessor,這個我真不展開說了,直接跳過吧,很少用的
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
}
catch (Throwable ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Post-processing of merged bean definition failed", ex);
}
mbd.postProcessed = true;
}
}
// 下面這塊代碼是爲了解決循環依賴的問題,以後有時間,我再對循環依賴這個問題進行解析吧
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isDebugEnabled()) {
logger.debug("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
// Initialize the bean instance.
Object exposedObject = bean;
try {
// 這一步也是非常關鍵的,這一步負責屬性裝配,因爲前面的實例只是實例化了,並沒有設值,這裏就是設值
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
// 還記得 init-method 嗎?還有 InitializingBean 接口?還有 BeanPostProcessor 接口?
// 這裏就是處理 bean 初始化完成後的各種回調
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
catch (Throwable ex) {
if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
throw (BeanCreationException) ex;
}
else {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
}
}
if (earlySingletonExposure) {
//
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
// Register bean as disposable.
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);
}
catch (BeanDefinitionValidationException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
}
return exposedObject;
}
到這裏,我們已經分析完了 doCreateBean 方法,總的來說,我們已經說完了整個初始化流程。
接下來我們挑 doCreateBean 中的三個細節出來說說。一個是創建 Bean 實例的 createBeanInstance 方法,一個是依賴注入的 populateBean 方法,還有就是回調方法 initializeBean。
注意了,接下來的這三個方法要認真說那也是極其複雜的,很多地方我就點到爲止了,感興趣的讀者可以自己往裏看,最好就是碰到不懂的,自己寫代碼去調試它。
創建 Bean 實例
我們先看看 createBeanInstance 方法。需要說明的是,這個方法如果每個分支都分析下去,必然也是極其複雜冗長的,我們挑重點說。此方法的目的就是實例化我們指定的類。
protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
// 確保已經加載了此 class
Class<?> beanClass = resolveBeanClass(mbd, beanName);
// 校驗一下這個類的訪問權限
if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
}
if (mbd.getFactoryMethodName() != null) {
// 採用工廠方法實例化,不熟悉這個概念的讀者請看附錄,注意,不是 FactoryBean
return instantiateUsingFactoryMethod(beanName, mbd, args);
}
// 如果不是第一次創建,比如第二次創建 prototype bean。
// 這種情況下,我們可以從第一次創建知道,採用無參構造函數,還是構造函數依賴注入 來完成實例化
boolean resolved = false;
boolean autowireNecessary = false;
if (args == null) {
synchronized (mbd.constructorArgumentLock) {
if (mbd.resolvedConstructorOrFactoryMethod != null) {
resolved = true;
autowireNecessary = mbd.constructorArgumentsResolved;
}
}
}
if (resolved) {
if (autowireNecessary) {
// 構造函數依賴注入
return autowireConstructor(beanName, mbd, null, null);
}
else {
// 無參構造函數
return instantiateBean(beanName, mbd);
}
}
// 判斷是否採用有參構造函數
Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
if (ctors != null ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) {
// 構造函數依賴注入
return autowireConstructor(beanName, mbd, ctors, args);
}
// 調用無參構造函數
return instantiateBean(beanName, mbd);
}
挑個簡單的無參構造函數構造實例來看看:
protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
try {
Object beanInstance;
final BeanFactory parent = this;
if (System.getSecurityManager() != null) {
beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
return getInstantiationStrategy().instantiate(mbd, beanName, parent);
}
}, getAccessControlContext());
}
else {
// 實例化
beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
}
// 包裝一下,返回
BeanWrapper bw = new BeanWrapperImpl(beanInstance);
initBeanWrapper(bw);
return bw;
}
catch (Throwable ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
}
}
我們可以看到,關鍵的地方在於:
beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
這裏會進行實際的實例化過程,我們進去看看:
// SimpleInstantiationStrategy 59
@Override
public Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {
// 如果不存在方法覆寫,那就使用 java 反射進行實例化,否則使用 CGLIB,
// 方法覆寫 請參見附錄"方法注入"中對 lookup-method 和 replaced-method 的介紹
if (bd.getMethodOverrides().isEmpty()) {
Constructor<?> constructorToUse;
synchronized (bd.constructorArgumentLock) {
constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
if (constructorToUse == null) {
final Class<?> clazz = bd.getBeanClass();
if (clazz.isInterface()) {
throw new BeanInstantiationException(clazz, "Specified class is an interface");
}
try {
if (System.getSecurityManager() != null) {
constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {
@Override
public Constructor<?> run() throws Exception {
return clazz.getDeclaredConstructor((Class[]) null);
}
});
}
else {
constructorToUse = clazz.getDeclaredConstructor((Class[]) null);
}
bd.resolvedConstructorOrFactoryMethod = constructorToUse;
}
catch (Throwable ex) {
throw new BeanInstantiationException(clazz, "No default constructor found", ex);
}
}
}
// 利用構造方法進行實例化
return BeanUtils.instantiateClass(constructorToUse);
}
else {
// 存在方法覆寫,利用 CGLIB 來完成實例化,需要依賴於 CGLIB 生成子類,這裏就不展開了
return instantiateWithMethodInjection(bd, beanName, owner);
}
}
到這裏,我們就算實例化完成了。我們開始說怎麼進行屬性注入。
bean 屬性注入
// AbstractAutowireCapableBeanFactory 1203
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
// bean 實例的所有屬性都在這裏了
PropertyValues pvs = mbd.getPropertyValues();
if (bw == null) {
if (!pvs.isEmpty()) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
}
else {
// Skip property population phase for null instance.
return;
}
}
// 到這步的時候,bean 實例化完成(通過工廠方法或構造方法),但是還沒開始屬性設值,
// InstantiationAwareBeanPostProcessor 的實現類可以在這裏對 bean 進行狀態修改,
// 我也沒找到有實際的使用,所以我們暫且忽略這塊吧
boolean continueWithPropertyPopulation = true;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// 如果返回 false,代表不需要進行後續的屬性設值,也不需要再經過其他的 BeanPostProcessor 的處理
if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
continueWithPropertyPopulation = false;
break;
}
}
}
}
if (!continueWithPropertyPopulation) {
return;
}
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
// 通過名字找到所有屬性值,如果是 bean 依賴,先初始化依賴的 bean。記錄依賴關係
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
autowireByName(beanName, mbd, bw, newPvs);
}
// 通過類型裝配。複雜一些
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
autowireByType(beanName, mbd, bw, newPvs);
}
pvs = newPvs;
}
boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
if (hasInstAwareBpps || needsDepCheck) {
PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
if (hasInstAwareBpps) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// 這裏有個非常有用的 BeanPostProcessor 進到這裏: AutowiredAnnotationBeanPostProcessor
// 對採用 @Autowired、@Value 註解的依賴進行設值,這裏的內容也是非常豐富的,不過本文不會展開說了,感興趣的讀者請自行研究
pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
if (pvs == null) {
return;
}
}
}
}
if (needsDepCheck) {
checkDependencies(beanName, mbd, filteredPds, pvs);
}
}
// 設置 bean 實例的屬性值
applyPropertyValues(beanName, mbd, bw, pvs);
}
initializeBean
屬性注入完成後,這一步其實就是處理各種回調了。
protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
if (System.getSecurityManager() != null) {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
invokeAwareMethods(beanName, bean);
return null;
}
}, getAccessControlContext());
}
else {
// 如果 bean 實現了 BeanNameAware、BeanClassLoaderAware 或 BeanFactoryAware 接口,回調
invokeAwareMethods(beanName, bean);
}
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
// BeanPostProcessor 的 postProcessBeforeInitialization 回調
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try {
// 處理 bean 中定義的 init-method,
// 或者如果 bean 實現了 InitializingBean 接口,調用 afterPropertiesSet() 方法
invokeInitMethods(beanName, wrappedBean, mbd);
}
catch (Throwable ex) {
throw new BeanCreationException(
(mbd != null ? mbd.getResourceDescription() : null),
beanName, "Invocation of init method failed", ex);
}
if (mbd == null || !mbd.isSynthetic()) {
// BeanPostProcessor 的 postProcessAfterInitialization 回調
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
大家發現沒有,BeanPostProcessor 的兩個回調都發生在這邊,只不過中間處理了 init-method,是不是和讀者原來的認知有點不一樣了?
附錄
配置是否允許 Bean 覆蓋、是否允許循環依賴
我們說過,默認情況下,allowBeanDefinitionOverriding 屬性爲 null。如果在同一配置文件中 Bean id 或 name 重複了,會拋錯,但是如果不是同一配置文件中,會發生覆蓋。
可是有些時候我們希望在系統啓動的過程中就嚴格杜絕發生 Bean 覆蓋,因爲萬一出現這種情況,會增加我們排查問題的成本。
循環依賴說的是 A 依賴 B,而 B 又依賴 A。或者是 A 依賴 B,B 依賴 C,而 C 卻依賴 A。默認 allowCircularReferences 也是 null。
它們兩個屬性是一起出現的,必然可以在同一個地方一起進行配置。
添加這兩個屬性的作者 Juergen Hoeller 在這個 jira 的討論中說明了怎麼配置這兩個屬性。
public class NoBeanOverridingContextLoader extends ContextLoader {
@Override
protected void customizeContext(ServletContext servletContext, ConfigurableWebApplicationContext applicationContext) {
super.customizeContext(servletContext, applicationContext);
AbstractRefreshableApplicationContext arac = (AbstractRefreshableApplicationContext) applicationContext;
arac.setAllowBeanDefinitionOverriding(false);
}
}
public class MyContextLoaderListener extends org.springframework.web.context.ContextLoaderListener {
@Override
protected ContextLoader createContextLoader() {
return new NoBeanOverridingContextLoader();
}
}
<listener>
<listener-class>com.javadoop.MyContextLoaderListener</listener-class>
</listener>
profile
我們可以把不同環境的配置分別配置到單獨的文件中,舉個例子:
<beans profile="development"
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xsi:schemaLocation="...">
<jdbc:embedded-database id="dataSource">
<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
</jdbc:embedded-database>
</beans>
<beans profile="production"
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="...">
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
應該不必做過多解釋了吧,看每個文件第一行的 profile=”“。
當然,我們也可以在一個配置文件中使用:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="...">
<beans profile="development">
<jdbc:embedded-database id="dataSource">
<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
</jdbc:embedded-database>
</beans>
<beans profile="production">
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
</beans>
接下來的問題是,怎麼使用特定的 profile 呢?Spring 在啓動的過程中,會去尋找 “spring.profiles.active” 的屬性值,根據這個屬性值來的。那怎麼配置這個值呢?
Spring 會在這幾個地方尋找 spring.profiles.active 的屬性值:操作系統環境變量、JVM 系統變量、web.xml 中定義的參數、JNDI。
最簡單的方式莫過於在程序啓動的時候指定:
-Dspring.profiles.active="profile1,profile2"
profile 可以激活多個
當然,我們也可以通過代碼的形式從 Environment 中設置 profile:
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("development");
ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
ctx.refresh(); // 重啓
如果是 Spring Boot 的話更簡單,我們一般會創建 application.properties、application-dev.properties、application-prod.properties 等文件,其中 application.properties 配置各個環境通用的配置,application-{profile}.properties 中配置特定環境的配置,然後在啓動的時候指定 profile:
java -Dspring.profiles.active=prod -jar JavaDoop.jar
如果是單元測試中使用的話,在測試類中使用 @ActiveProfiles 指定,這裏就不展開了。
工廠模式生成 Bean
請讀者注意 factory-bean 和 FactoryBean 的區別。這節說的是前者,是說靜態工廠或實例工廠,而後者是 Spring 中的特殊接口,代表一類特殊的 Bean,附錄的下面一節會介紹 FactoryBean。
設計模式裏,工廠方法模式分靜態工廠和實例工廠,我們分別看看 Spring 中怎麼配置這兩個,來個代碼示例就什麼都清楚了。
靜態工廠:
<bean id="clientService"
class="examples.ClientService"
factory-method="createInstance"/>
public class ClientService {
private static ClientService clientService = new ClientService();
private ClientService() {}
// 靜態方法
public static ClientService createInstance() {
return clientService;
}
}
實例工廠:
<bean id="serviceLocator" class="examples.DefaultServiceLocator">
<!-- inject any dependencies required by this locator bean -->
</bean>
<bean id="clientService"
factory-bean="serviceLocator"
factory-method="createClientServiceInstance"/>
<bean id="accountService"
factory-bean="serviceLocator"
factory-method="createAccountServiceInstance"/>
public class DefaultServiceLocator {
private static ClientService clientService = new ClientServiceImpl();
private static AccountService accountService = new AccountServiceImpl();
public ClientService createClientServiceInstance() {
return clientService;
}
public AccountService createAccountServiceInstance() {
return accountService;
}
}
FactoryBean
FactoryBean 適用於 Bean 的創建過程比較複雜的場景,比如數據庫連接池的創建。
public interface FactoryBean<T> {
T getObject() throws Exception;
Class<T> getObjectType();
boolean isSingleton();
}
public class Person {
private Car car ;
private void setCar(Car car){ this.car = car; }
}
我們假設現在需要創建一個 Person 的 Bean,首先我們需要一個 Car 的實例,我們這裏假設 Car 的實例創建很麻煩,那麼我們可以把創建 Car 的複雜過程包裝起來:
public class MyCarFactoryBean implements FactoryBean<Car>{
private String make;
private int year ;
public void setMake(String m){ this.make =m ; }
public void setYear(int y){ this.year = y; }
public Car getObject(){
// 這裏我們假設 Car 的實例化過程非常複雜,反正就不是幾行代碼可以寫完的那種
CarBuilder cb = CarBuilder.car();
if(year!=0) cb.setYear(this.year);
if(StringUtils.hasText(this.make)) cb.setMake( this.make );
return cb.factory();
}
public Class<Car> getObjectType() { return Car.class ; }
public boolean isSingleton() { return false; }
}
我們看看裝配的時候是怎麼配置的:
<bean class = "com.javadoop.MyCarFactoryBean" id = "car">
<property name = "make" value ="Honda"/>
<property name = "year" value ="1984"/>
</bean>
<bean class = "com.javadoop.Person" id = "josh">
<property name = "car" ref = "car"/>
</bean>
看到不一樣了嗎?id 爲 “car” 的 bean 其實指定的是一個 FactoryBean,不過配置的時候,我們直接讓配置 Person 的 Bean 直接依賴於這個 FactoryBean 就可以了。中間的過程 Spring 已經封裝好了。
說到這裏,我們再來點乾貨。我們知道,現在還用 xml 配置 Bean 依賴的越來越少了,更多時候,我們可能會採用 java config 的方式來配置,這裏有什麼不一樣呢?
@Configuration
public class CarConfiguration {
@Bean
public MyCarFactoryBean carFactoryBean(){
MyCarFactoryBean cfb = new MyCarFactoryBean();
cfb.setMake("Honda");
cfb.setYear(1984);
return cfb;
}
@Bean
public Person aPerson(){
Person person = new Person();
// 注意這裏的不同
person.setCar(carFactoryBean().getObject());
return person;
}
}
這個時候,其實我們的思路也很簡單,把 MyCarFactoryBean 看成是一個簡單的 Bean 就可以了,不必理會什麼 FactoryBean,它是不是 FactoryBean 和我們沒關係。
初始化 Bean 的回調
有以下四種方案:
<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>
public class AnotherExampleBean implements InitializingBean {
public void afterPropertiesSet() {
// do some initialization work
}
}
@Bean(initMethod = "init")
public Foo foo() {
return new Foo();
}
@PostConstruct
public void init() {
}
銷燬 Bean 的回調
<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>
public class AnotherExampleBean implements DisposableBean {
public void destroy() {
// do some destruction work (like releasing pooled connections)
}
}
@Bean(destroyMethod = "cleanup")
public Bar bar() {
return new Bar();
}
@PreDestroy
public void cleanup() {
}
ConversionService
既然文中說到了這個,順便提一下好了。
最有用的場景就是,它用來將前端傳過來的參數和後端的 controller 方法上的參數進行綁定的時候用。
像前端傳過來的字符串、整數要轉換爲後端的 String、Integer 很容易,但是如果 controller 方法需要的是一個枚舉值,或者是 Date 這些非基礎類型(含基礎類型包裝類)值的時候,我們就可以考慮採用 ConversionService 來進行轉換。
<bean id="conversionService"
class="org.springframework.context.support.ConversionServiceFactoryBean">
<property name="converters">
<list>
<bean class="com.javadoop.learning.utils.StringToEnumConverterFactory"/>
</list>
</property>
</bean>
ConversionService 接口很簡單,所以要自定義一個 convert 的話也很簡單。
下面再說一個實現這種轉換很簡單的方式,那就是實現 Converter 接口。
來看一個很簡單的例子,這樣比什麼都管用。
public class StringToDateConverter implements Converter<String, Date> {
@Override
public Date convert(String source) {
try {
return DateUtils.parseDate(source, "yyyy-MM-dd", "yyyy-MM-dd HH:mm:ss", "yyyy-MM-dd HH:mm", "HH:mm:ss", "HH:mm");
} catch (ParseException e) {
return null;
}
}
}
只要註冊這個 Bean 就可以了。這樣,前端往後端傳的時間描述字符串就很容易綁定成 Date 類型了,不需要其他任何操作。
Bean 繼承
在初始化 Bean 的地方,我們說過了這個:
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
這裏涉及到的就是 中的 parent 屬性,我們來看看 Spring 中是用這個來幹什麼的。
首先,我們要明白,這裏的繼承和 java 語法中的繼承沒有任何關係,不過思路是相通的。child bean 會繼承 parent bean 的所有配置,也可以覆蓋一些配置,當然也可以新增額外的配置。
Spring 中提供了繼承自 AbstractBeanDefinition 的 ChildBeanDefinition 來表示 child bean。
看如下一個例子:
<bean id="inheritedTestBean" abstract="true" class="org.springframework.beans.TestBean">
<property name="name" value="parent"/>
<property name="age" value="1"/>
</bean>
<bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean"
parent="inheritedTestBean" init-method="initialize">
<property name="name" value="override"/>
</bean>
parent bean 設置了 abstract=”true” 所以它不會被實例化,child bean 繼承了 parent bean 的兩個屬性,但是對 name 屬性進行了覆寫。
child bean 會繼承 scope、構造器參數值、屬性值、init-method、destroy-method 等等。
當然,我不是說 parent bean 中的 abstract = true 在這裏是必須的,只是說如果加上了以後 Spring 在實例化 singleton beans 的時候會忽略這個 bean。
比如下面這個極端 parent bean,它沒有指定 class,所以毫無疑問,這個 bean 的作用就是用來充當模板用的 parent bean,此處就必須加上 abstract = true。
<bean id="inheritedTestBeanWithoutClass" abstract="true">
<property name="name" value="parent"/>
<property name="age" value="1"/>
</bean>
方法注入
一般來說,我們的應用中大多數的 Bean 都是 singleton 的。singleton 依賴 singleton,或者 prototype 依賴 prototype 都很好解決,直接設置屬性依賴就可以了。
但是,如果是 singleton 依賴 prototype 呢?這個時候不能用屬性依賴,因爲如果用屬性依賴的話,我們每次其實拿到的還是第一次初始化時候的 bean。
一種解決方案就是不要用屬性依賴,每次獲取依賴的 bean 的時候從 BeanFactory 中取。這個也是大家最常用的方式了吧。怎麼取,我就不介紹了,大部分 Spring 項目大家都會定義那麼個工具類的。
另一種解決方案就是這裏要介紹的通過使用 Lookup method。
lookup-method
我們來看一下 Spring Reference 中提供的一個例子:
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
xml 配置 <lookup-method />
:
<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
<!-- inject dependencies here as required -->
</bean>
<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
<lookup-method name="createCommand" bean="myCommand"/>
</bean>
Spring 採用 CGLIB 生成字節碼的方式來生成一個子類。我們定義的類不能定義爲 final class,抽象方法上也不能加 final。
lookup-method 上的配置也可以採用註解來完成,這樣就可以不用配置<lookup-method />
了,其他不變:
public abstract class CommandManager {
public Object process(Object commandState) {
MyCommand command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup("myCommand")
protected abstract Command createCommand();
}
注意,既然用了註解,要配置註解掃描:
<context:component-scan base-package="com.javadoop" /></blockquote>
甚至,我們可以像下面這樣:
public abstract class CommandManager {
public Object process(Object commandState) {
MyCommand command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup
protected abstract MyCommand createCommand();
}
上面的返回值用了 MyCommand,當然,如果 Command 只有一個實現類,那返回值也可以寫 Command。
replaced-method
能,就是替換掉 bean 中的一些方法。
public class MyValueCalculator {
public String computeValue(String input) {
// some real code...
}
// some other methods...
}
方法覆寫,注意要實現 MethodReplacer 接口:
public class ReplacementComputeValue implements org.springframework.beans.factory.support.MethodReplacer {
public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
// get the input value, work with it, and return a computed result
String input = (String) args[0];
...
return ...;
}
}
配置也很簡單:
<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
<!-- 定義 computeValue 這個方法要被替換掉 -->
<replaced-method name="computeValue" replacer="replacementComputeValue">
<arg-type>String</arg-type>
</replaced-method>
</bean>
<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>
arg-type 明顯不是必須的,除非存在方法重載,這樣必須通過參數類型列表來判斷這裏要覆蓋哪個方法。
BeanPostProcessor
應該說 BeanPostProcessor 概念在 Spring 中也是比較重要的。我們看下接口定義:
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
看這個接口中的兩個方法名字我們大體上可以猜測 bean 在初始化之前會執行 postProcessBeforeInitialization 這個方法,初始化完成之後會執行 postProcessAfterInitialization 這個方法。但是,這麼理解是非常片面的。
首先,我們要明白,除了我們自己定義的 BeanPostProcessor 實現外,Spring 容器在啓動時自動給我們也加了幾個。如在獲取 BeanFactory 的 obtainFactory() 方法結束後的 prepareBeanFactory(factory),大家仔細看會發現,Spring 往容器中添加了這兩個BeanPostProcessor:ApplicationContextAwareProcessor,ApplicationListenerDetector。
我們回到這個接口本身,讀者請看第一個方法,這個方法接受的第一個參數是 bean 實例,第二個參數是 bean 的名字,重點在返回值將會作爲新的 bean 實例,所以,沒事的話這裏不能隨便返回個 null。
那意味着什麼呢?我們很容易想到的就是,我們這裏可以對一些我們想要修飾的 bean 實例做一些事情。但是對於 Spring 框架來說,它會決定是不是要在這個方法中返回 bean 實例的代理,這樣就有更大的想象空間了。
最後,我們說說如果我們自己定義一個 bean 實現 BeanPostProcessor 的話,它的執行時機是什麼時候?
如果仔細看了代碼分析的話,其實很容易知道了,在 bean 實例化完成、屬性注入完成之後,會執行回調方法,具體請參見AbstractAutowireCapableBeanFactory .initializeBean
方法。
首先會回調幾個實現了 Aware 接口的 bean,然後就開始回調 BeanPostProcessor 的 postProcessBeforeInitialization 方法,之後是回調 init-method,然後再回調 BeanPostProcessor 的 postProcessAfterInitialization 方法。
總結
按理說,總結應該寫在附錄前面,我就不講究了。
在花了那麼多時間後,這篇文章終於算是基本寫完了,大家在驚歎 Spring 給我們做了那麼多的事的時候,應該透過現象看本質,去理解 Spring 寫得好的地方,去理解它的設計思想。
本文的缺陷在於對 Spring 預初始化 singleton beans 的過程分析不夠,主要是代碼量真的比較大,分支旁路衆多。同時,雖然附錄條目不少,但是龐大的 Spring 真的引出了很多的概念,希望日後有精力可以慢慢補充一些。