前言
傳統的spring做法是使用.xml文件來對bean進行注入或者是配置aop、事物，這么做有兩個缺點：
1、如果所有的內容都配置在.xml文件中，那么.xml文件將會十分龐大；如果按需求分開.xml文件，那么.xml文件又會非常多。總之這將導致配置文件的可讀性與可維護性變得很低。
2、在開發中在.java文件和.xml文件之間不斷切換，是一件麻煩的事，同時這種思維上的不連貫也會降低開發的效率。
為了解決這兩個問題，spring引入了注解，通過"@xxx"的方式，讓注解與java bean緊密結合，既大大減少了配置文件的體積，又增加了java bean的可讀性與內聚性。
如果你看到了注解,那么一定有什么代碼在什么地方處理了它.
alan hohn
我教java課程時強調的一點是注解是惰性的。換句話說，它們只是標記，可能具有某些屬性，但沒有自己的行為。因此，每當你在一段java代碼上看到一個注解時，就意味著必須有一些其他的java代碼來尋找那個注解并包含真正的智能來做一些有用的東西。
不幸的是，這種推理的問題在于，確切地確定哪一段代碼正在處理注解是非常困難的，特別是如果它在庫中。處理注解的代碼可能會令人困惑，因為它使用反射并且必須以非常抽象的方式編寫。所以我認為值得看看一個做得很好的例子來看看它是如何運行的。
我們詳細研究一下 spring 框架中的 initdestroyannotationbeanpostprocessor 類是如何工作的。選擇這個，因為它相對簡單，只做了一些相對容易解釋的事情, 碰巧和我手頭的工作相關。
spring bean 的后處理
首先，我想首先解釋一下 spring 的用途。spring 框架所做的一件事就是“依賴注入”。這改變了我們以往用代碼將模塊串在一起的方式。例如，假設我們編寫了一些需要連接數據庫的應用程序邏輯, 但并想將提供該連接的特定硬類編碼到應用程序邏輯中，我們可以在構造函數或setter方法中將其表示為依賴項：
|
1
2
3
4
5
6
7
8
|
class myapplication { private dataconnection data; ... public void setdata(dataconnection data) { this.data = data; } ...} |
當然，如果想的話, 我們可以自己編寫一個簡單的庫完成這種依賴注入，從而避免添加對 spring 的依賴項。但是如果我們在編寫一個復雜的應用程序, 想將各模塊連接在一起，那么spring可以非常方便。
既然沒有什么神秘的，如果我們要讓 spring 為我們注入這些依賴，那么就會有一個權衡。spring 需要“知道”依賴關系以及應用程序中的類和對象。spring 處理這個問題的方法多是由 spring 框架對對象進行實例化; 從而可以在稱為"應用程序上下文"的大數據結構中跟蹤管理這此對象。
后處理和初始化
而且這里是 initdestroybeanpostprocessor 進入的地方 。如果 spring 要處理實例化，那么在對象實例化完成之后，但是在應用程序開始真正的運行之前，需要進行一些“額外工作”。需要做的一件“額外工作”就是調用對象來告訴他們什么時候完全設置好，這樣他們就可以進行任何需要的額外初始化。如果我們使用“setter”注入，如上所述，便通過調用setxxx() 方法注入依賴項，這一點尤其重要，因為在調用對象的構造函數時這些依賴項并不可用。所以 spring 需要允許用戶指定在初始化對象后才應該調用的某個方法的名稱。
spring 一直支持使用xml配置文件來定義由 spring 來實例化的對象，在這種情況下，有一個 'init-method' 屬性可以用來指定初始化的方法。顯然，在這種情況下，它仍然需要反射來實際查找并調用該方法。自java 5起, 增加了注解，所以spring 也支持帶注解的標記方法，將它們標識為spring應該實例化的對象，識別需要注入的依賴項，以及識別應該調用的初始化和銷毀??方法。
最后一項 initdestroybeanpostprocessor 由其子類或其中一個子類處理。后處理器是一種特殊的對象，由spring實例化，實現后處理器接口。因為它實現了這個接口，所以spring會在每個spring實例化的對象上調用一個方法，允許它修改甚至替換該對象。這是spring采用模塊化架構方法的一部分，可以更輕松地擴展功能。
這是怎么運作的?
事實上， jsr-250 確定了一些“常見”注解，包括 @postconstruct, 用于標記初始化方法,@predestroy 注解, 用于注解銷毀方法的。不同的是，initdestroybeanpostprocessor 被設計成可以處理任何注解集，因此它提供了識別注解的方法：
|
1
2
3
4
5
6
7
|
public void setinitannotationtype(class<? extends annotation> initannotationtype) { this.initannotationtype = initannotationtype; }... public void setdestroyannotationtype(class<? extends annotation> destroyannotationtype) { this.destroyannotationtype = destroyannotationtype; } |
請注意，這些是普通的 setter 方法，因此這個對象本身可以使用 spring 進行設置。就我而言，我使用spring 的 staticapplicationcontext，見我。
一旦 spring 實例化了各種對象并注入了所有依賴項，它就會在所有后處理器上為每個對象調用 postprocessbeforeinitialization 方法 。這使后處理器有機會在初始化之前修改或替換對象。因為已經注入了依賴項，所以這是 initdestroyannotationbeanpostprocessor 調用初始化方法的地方。
|
1
2
3
4
|
lifecyclemetadata metadata = findlifecyclemetadata(bean.getclass());try { metadata.invokeinitmethods(bean, beanname);} |
由于我們對代碼如何處理注解感興趣，我們感興趣 findlifecyclemetadata() 方法，因為這是對類進行檢查的地方。該方法檢查緩存，該緩存用于避免執行超過必要的反射，因為它可能很昂貴。如果尚未檢查該類，則調用 buildlifecyclemetadata() 方法。該方法的內容如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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 是一個方便的類，簡化了反射的使用。除此之外，它還將經過反射的眾多已檢查異常轉換為未經檢查的異常(?)，從而使事情變得更容易。此特定方法僅迭代本地方法（即不是繼承的方法），并為每個方法調用回調。
完成所有設置之后，檢查注解的部分非常無聊; 它只是調用java反射方法來檢查注解，如果找到它，則將該方法存儲為初始化方法。
總結
事實上，這里最終發生的事情很簡單，這就是我在教反射時所要做的事情。調試使用注解來控制行為的代碼可能具有挑戰性，因為從外部來看它非常不透明，所以很難想象發生了什么（或者沒有發生）和什么時候發生。但最終，正在發生的事情只是java代碼; 它可能不會立即顯現出代碼的位置，但它就在那里。
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://segmentfault.com/a/1190000016989746
