前言

傳統(tǒng)的Spring做法是使用.xml文件來(lái)對(duì)bean進(jìn)行注入或者是配置aop、事物，這么做有兩個(gè)缺點(diǎn)：

1、如果所有的內(nèi)容都配置在.xml文件中，那么.xml文件將會(huì)十分龐大；如果按需求分開(kāi).xml文件，那么.xml文件又會(huì)非常多?？傊@將導(dǎo)致配置文件的可讀性與可維護(hù)性變得很低。

2、在開(kāi)發(fā)中在.java文件和.xml文件之間不斷切換，是一件麻煩的事，同時(shí)這種思維上的不連貫也會(huì)降低開(kāi)發(fā)的效率。
為了解決這兩個(gè)問(wèn)題，Spring引入了注解，通過(guò)"@XXX"的方式，讓注解與Java Bean緊密結(jié)合，既大大減少了配置文件的體積，又增加了Java Bean的可讀性與內(nèi)聚性。

如果你看到了注解,那么一定有什么代碼在什么地方處理了它.

Alan Hohn

我教Java課程時(shí)強(qiáng)調(diào)的一點(diǎn)是注解是惰性的。換句話說(shuō)，它們只是標(biāo)記，可能具有某些屬性，但沒(méi)有自己的行為。因此，每當(dāng)你在一段Java代碼上看到一個(gè)注解時(shí)，就意味著必須有一些其他的Java代碼來(lái)尋找那個(gè)注解并包含真正的智能來(lái)做一些有用的東西。

不幸的是，這種推理的問(wèn)題在于，確切地確定哪一段代碼正在處理注解是非常困難的，特別是如果它在庫(kù)中。處理注解的代碼可能會(huì)令人困惑，因?yàn)樗褂梅瓷洳⑶冶仨氁苑浅３橄蟮姆绞骄帉?xiě)。所以我認(rèn)為值得看看一個(gè)做得很好的例子來(lái)看看它是如何運(yùn)行的。

我們?cè)敿?xì)研究一下 Spring 框架中的 InitDestroyAnnotationBeanPostProcessor 類(lèi)是如何工作的。選擇這個(gè)，因?yàn)樗鄬?duì)簡(jiǎn)單，只做了一些相對(duì)容易解釋的事情, 碰巧和我手頭的工作相關(guān)。

Spring Bean 的后處理

首先，我想首先解釋一下 Spring 的用途。Spring 框架所做的一件事就是“依賴(lài)注入”。這改變了我們以往用代碼將模塊串在一起的方式。例如，假設(shè)我們編寫(xiě)了一些需要連接數(shù)據(jù)庫(kù)的應(yīng)用程序邏輯, 但并想將提供該連接的特定硬類(lèi)編碼到應(yīng)用程序邏輯中，我們可以在構(gòu)造函數(shù)或setter方法中將其表示為依賴(lài)項(xiàng)：

class MyApplication {
 private DataConnection data;
 ...
 public void setData(DataConnection data) {
  this.data = data;
 }
 ...
}

當(dāng)然，如果想的話, 我們可以自己編寫(xiě)一個(gè)簡(jiǎn)單的庫(kù)完成這種依賴(lài)注入，從而避免添加對(duì) Spring 的依賴(lài)項(xiàng)。但是如果我們?cè)诰帉?xiě)一個(gè)復(fù)雜的應(yīng)用程序, 想將各模塊連接在一起，那么Spring可以非常方便。

既然沒(méi)有什么神秘的，如果我們要讓 Spring 為我們注入這些依賴(lài)，那么就會(huì)有一個(gè)權(quán)衡。Spring 需要“知道”依賴(lài)關(guān)系以及應(yīng)用程序中的類(lèi)和對(duì)象。Spring 處理這個(gè)問(wèn)題的方法多是由 Spring 框架對(duì)對(duì)象進(jìn)行實(shí)例化; 從而可以在稱(chēng)為"應(yīng)用程序上下文"的大數(shù)據(jù)結(jié)構(gòu)中跟蹤管理這此對(duì)象。

后處理和初始化

而且這里是 InitDestroyBeanPostProcessor 進(jìn)入的地方 。如果 Spring 要處理實(shí)例化，那么在對(duì)象實(shí)例化完成之后，但是在應(yīng)用程序開(kāi)始真正的運(yùn)行之前，需要進(jìn)行一些“額外工作”。需要做的一件“額外工作”就是調(diào)用對(duì)象來(lái)告訴他們什么時(shí)候完全設(shè)置好，這樣他們就可以進(jìn)行任何需要的額外初始化。如果我們使用“setter”注入，如上所述，便通過(guò)調(diào)用setXxx() 方法注入依賴(lài)項(xiàng)，這一點(diǎn)尤其重要，因?yàn)樵谡{(diào)用對(duì)象的構(gòu)造函數(shù)時(shí)這些依賴(lài)項(xiàng)并不可用。所以 Spring 需要允許用戶(hù)指定在初始化對(duì)象后才應(yīng)該調(diào)用的某個(gè)方法的名稱(chēng)。

Spring 一直支持使用XML配置文件來(lái)定義由 Spring 來(lái)實(shí)例化的對(duì)象，在這種情況下，有一個(gè) 'init-method' 屬性可以用來(lái)指定初始化的方法。顯然，在這種情況下，它仍然需要反射來(lái)實(shí)際查找并調(diào)用該方法。自Java 5起, 增加了注解，所以Spring 也支持帶注解的標(biāo)記方法，將它們標(biāo)識(shí)為Spring應(yīng)該實(shí)例化的對(duì)象，識(shí)別需要注入的依賴(lài)項(xiàng)，以及識(shí)別應(yīng)該調(diào)用的初始化和銷(xiāo)毀​​方法。

最后一項(xiàng) InitDestroyBeanPostProcessor 由其子類(lèi)或其中一個(gè)子類(lèi)處理。后處理器是一種特殊的對(duì)象，由Spring實(shí)例化，實(shí)現(xiàn)后處理器接口。因?yàn)樗鼘?shí)現(xiàn)了這個(gè)接口，所以Spring會(huì)在每個(gè)Spring實(shí)例化的對(duì)象上調(diào)用一個(gè)方法，允許它修改甚至替換該對(duì)象。這是Spring采用模塊化架構(gòu)方法的一部分，可以更輕松地?cái)U(kuò)展功能。

這是怎么運(yùn)作的?

事實(shí)上， JSR-250 確定了一些“常見(jiàn)”注解，包括 @PostConstruct, 用于標(biāo)記初始化方法,@PreDestroy 注解, 用于注解銷(xiāo)毀方法的。不同的是，InitDestroyBeanPostProcessor 被設(shè)計(jì)成可以處理任何注解集，因此它提供了識(shí)別注解的方法：

 public void setInitAnnotationType(Class<? extends Annotation> initAnnotationType) {
  this.initAnnotationType = initAnnotationType;
 }
...
 public void setDestroyAnnotationType(Class<? extends Annotation> destroyAnnotationType) {
  this.destroyAnnotationType = destroyAnnotationType;
 }

請(qǐng)注意，這些是普通的 setter 方法，因此這個(gè)對(duì)象本身可以使用 Spring 進(jìn)行設(shè)置。就我而言，我使用Spring 的 StaticApplicationContext，見(jiàn)我以前的文章。

一旦 Spring 實(shí)例化了各種對(duì)象并注入了所有依賴(lài)項(xiàng)，它就會(huì)在所有后處理器上為每個(gè)對(duì)象調(diào)用 postProcessBeforeInitialization 方法 。這使后處理器有機(jī)會(huì)在初始化之前修改或替換對(duì)象。因?yàn)橐呀?jīng)注入了依賴(lài)項(xiàng)，所以這是 InitDestroyAnnotationBeanPostProcessor 調(diào)用初始化方法的地方。

 LifecycleMetadata metadata = findLifecycleMetadata(bean.getClass());
 try {
  metadata.invokeInitMethods(bean, beanName);
 }

由于我們對(duì)代碼如何處理注解感興趣，我們感興趣 findLifecycleMetadata() 方法，因?yàn)檫@是對(duì)類(lèi)進(jìn)行檢查的地方。該方法檢查緩存，該緩存用于避免執(zhí)行超過(guò)必要的反射，因?yàn)樗赡芎馨嘿F。如果尚未檢查該類(lèi)，則調(diào)用 buildLifecycleMetadata() 方法。該方法的內(nèi)容如下：

ReflectionUtils.doWithLocalMethods(targetClass, new ReflectionUtils.MethodCallback() {
 @Override
 public void doWith(Method method) throws IllegalArgumentException, IllegalAccessException {
  if (initAnnotationType != null) {
   if (method.getAnnotation(initAnnotationType) != null) {
    LifecycleElement element = new LifecycleElement(method);
    currInitMethods.add(element);
   }
  }
  ...
 }
});

這里 ReflectionUtils 是一個(gè)方便的類(lèi)，簡(jiǎn)化了反射的使用。除此之外，它還將經(jīng)過(guò)反射的眾多已檢查異常轉(zhuǎn)換為未經(jīng)檢查的異常(?)，從而使事情變得更容易。此特定方法僅迭代本地方法（即不是繼承的方法），并為每個(gè)方法調(diào)用回調(diào)。

完成所有設(shè)置之后，檢查注解的部分非常無(wú)聊; 它只是調(diào)用Java反射方法來(lái)檢查注解，如果找到它，則將該方法存儲(chǔ)為初始化方法。

總結(jié)

事實(shí)上，這里最終發(fā)生的事情很簡(jiǎn)單，這就是我在教反射時(shí)所要做的事情。調(diào)試使用注解來(lái)控制行為的代碼可能具有挑戰(zhàn)性，因?yàn)閺耐獠縼?lái)看它非常不透明，所以很難想象發(fā)生了什么（或者沒(méi)有發(fā)生）和什么時(shí)候發(fā)生。但最終，正在發(fā)生的事情只是Java代碼; 它可能不會(huì)立即顯現(xiàn)出代碼的位置，但它就在那里。

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。