javascript
品Spring：bean定义上梁山
?
?
技術不枯燥，先來點閑聊
先說點好事高興一下。前段時間看新聞說，我國正式的空間站建設已在進行當中。下半年，長征五號B運載火箭將在海南文昌航天發射場擇機將空間站核心艙發射升空。預計用2到3年將空間站建好。
雖然到時你們不讓我上去，不過我也為這件事出不了什么力，算扯平了。哈哈，但是我還是會衷心的祝福你。
長征五號火箭首次采用5米大直徑的箭體結構，總加注量達到780噸，起飛時共有10臺發動機產生1078噸的推力，具備近地軌道25噸、地球同步轉移軌道14噸的運載能力。
不要誤會，本文不是講火箭的，關鍵我也講不了呀。但是我們可以分析下火箭的特點。自身體積和重量非常大，內部結構與實現極其復雜。能夠運送的物品與自身比起來微乎其微，關鍵這玩意老貴老貴了。
因此SpaceX推出的獵鷹可回收火箭，從一開始就受到了全世界的關注。回收之后可以被重新利用，不但縮短了火箭發射的周期，平均下來每次發射的成本也少了很多。享受同樣的服務，花更少的錢，不是所有人的最愛嘛。
回到程序，其實現在大部分程序員，包括我自己在內都應該屬于2.0或3.0版本的程序員，因為我們的職業生涯都是從Spring開始的。在Spring之前Java企業級應用開發標準其實是EJB（企業級JavaBean）。
EJB只是一個標準或規范，由各大服務提供商來實現。EJB非常笨重而且用起來也痛苦，關鍵還很貴。其實和火箭的性質一樣，自身的負擔太重。這個問題必須要解決。
因此，Elon Musk認識到了這點，就開始著手研制可回收火箭。在當時，Rod Johnson也認識到了EJB特點并深受其害，于是發明了Spring，輕量級、免費開源，慢慢就流行起來了。
看到了吧，在工作或生活中，凡是遇到苦逼的地方，就說明這也是一個極有可能產生大成功的地方。這個秘密我可是告訴諸位了，能不能成功就看你們的了。哈哈。
其實Spring現在也已經變得足夠復雜了。
要想渡人，必先渡己
易中天老師曾說過，能夠制造工具標志著人類的誕生。目前人類建造的文明，哪一個是通過雙手刨出來的，不都是通過工具建造出來的嘛。
比如我們蓋高樓用的建材，不都是通過塔吊一點點吊上去的，隨著建材的堆砌，樓越來越高。那么我們來思考一個問題，塔吊本身是如何上去的？
塔吊本身就是一個工具了，所以（一般情況下）不可能再有其它工具來幫它了。所以塔吊只能實現自我爬升，實際也是這樣的，相信大多人都見過，速度很慢的。
我們都在用Windows操作系統，點點鼠標，敲敲鍵盤，用著很爽。但是在開發Windows系統本身時卻是很苦逼的一件事。
我主要想表達兩方面的意思：
如果有一天，我們能從工具的使用者變成設計者或制造者，那就厲害多了。
還有就是，一個工具在對外提供服務前，一定要解決好自身的搭建或構建問題。
Spring其實就是個工具，開發人員把業務代碼寫好后，把類作為bean注冊到工具上，后續的運行時全部交由Spring這個工具接管，簡直不要太爽。
當然，這也是Spring存在的價值和意義。但是不要忘了，建造Spring這個工具的那批人可就不爽了，為了“取悅”這個工具的使用者天天挖空心思。
所以“品Spring”這個系列文章，是想要逐步解密Spring這個工具的建造細節，而不是教怎么使用這個工具的。目前還不能熟練使用這個工具的小伙伴可就要加油了。
所以Spring這個工具應該優先考慮好自我的搭建，才能更好的為開發員人服務。
就像開發人員，必須有一個良好的家庭，吃飽喝足睡夠之后，才能寫出水平最高的代碼。如果剛在家和老婆吵完架，那寫出的代碼應該都是bug的樣子，哈哈。
相同的套路，相似的處理
編譯器是編譯代碼的，但它本身也是代碼。飯店的工作人員是服務客人吃飯的，但他們本身也要吃飯。指針是指向地址的，但它們本身也有地址。
描述業務的數據通常稱為業務數據，描述業務數據的數據通常稱為元數據。業務數據和元數據都是數據，只不過是取了兩個更加細化的名字罷了。
上面描述的這些情形里面都包含了兩方面的事物，可以理解為是“一前一后”的感覺。它們既不是相同也不是不同，而是相似。即處理方式相同，側重點不同。
就以飯店為例吧，這個所有人都熟悉。給客人做的飯，要求色香味俱全，即當作藝術品來對待。員工自己吃的飯，要求味美可口簡單快捷，即當作食物來對待。
因為客人和員工的要求不同，所以處理的側重點、工序和用料不同，但是處理方式大致都一樣，無非就是煎炒炸蒸煮等等。
相信都已經明白了，如果還不清楚，就想想蓋商品房、蓋集資房和蓋職工宿舍有什么區別？本質上沒有區別，而且還可能是同一個施工隊干的。
回到程序，經常聽到說做中間件開發的人都很厲害，寫純業務代碼的好像都是菜鳥。怎么說呢，做中間件和做業務確實目的不同、側重點不同、用到的技術不同，所以要求也不同。
寫出代碼的好壞只取決于個人水平，因為中間件代碼和業務代碼沒有本質的區別，都是對數據的操作和傳遞，都是順序分支循環的程序結構。
而且都是用同一個編譯器編譯，關鍵編譯器才不管你是什么代碼呢，反正都是Java代碼，對吧，哈哈。
回到Spring，既然Spring能把業務開發人員寫的業務類作為bean來對待（即注冊bean定義），難道就不能把用來處理這些業務類的“系統類”（即Spring自身的類）也當作bean來對待嗎？
答案是完全可以，而且實際也是這樣做的。本來業務類和系統類就是人為劃分的，本質上都是程序，沒啥區別。
都作為bean來對待后，帶來了一個非常好非常好的好處，就是統一了編程模型，這非常重要。
就是業務開發人員可以使用@Component/@Bean注冊bean定義，使用@Autowired裝配bean依賴?？蚣荛_發人員在開發Spring框架時也可以這樣使用。
這樣就模式統一、寫法統一、思維統一，當然很爽了。
可以這樣理解，在建造這個工具時，就已經可以享受這個工具帶來的便利了。
如果無法體會到這種好處的，照例通過一個小事情說明下。
比如一群中國人，彼此協作的很好，突然來了一個老外，互相又聽不懂對方，但是還要交流，只要讓翻譯在中間翻來覆去，是不是凈瞎耽誤工夫，肯定是不爽的。
當然，這個事情有時也是不成立的，比如老外是一個年輕漂亮的小姐姐，是吧，所以說任何事情都不是絕對的。
Spring統一了編程模型后，Spring自身的類和業務類都注冊了bean定義，那這些bean定義間真的就完全一樣嗎？
答案當然是否定的，畢竟作用不同，肯定是有差別的，只是大小罷了。
身先士卒，沖鋒陷陣
業務類注冊bean定義的目的是為了將來運行這個bean實現業務邏輯的。那么它的bean定義是怎么注冊的呢？顯然是Spring為它注冊的。
因此在Spring內部，有一個專門為其它類注冊bean定義的接口，即BeanDefinitionRegistryPostProcessor接口：
?
接口只有一個方法，就是注冊bean定義。
這個接口有一個非常重要的實現類，即ConfigurationClassPostProcessor類，它里面包含了所有Spring支持的注冊bean定義方式的實現。
因Spring統一了編程模型，所以這個類也被注冊了bean定義。又因為這個bean只有運行起來后才可以為其它類注冊bean定義，所有這個類無論是注冊bean定義還是運行，在時間軸上都是比較靠前的。
事實上，它是Spring注冊的第一個bean定義，bean的類就是剛才提到的那個實現類，bean的名稱是：
?
說白了這個類就是用來處理那些使用注解標注的類，為它們注冊bean定義的。所以這個類它自己的bean定義注冊絕對不能再使用注解的方式，而是使用代碼直接注冊的，可以認為是寫死的。
通過高鐵乘務員和旅客的這種情況，可能會理解的更明白些。
1、乘務員是人，旅客也是人，他們都是人?？蚣芾锏念愖詁ean定義，業務類注冊bean定義，它們都注冊bean定義。
2、乘務員必須先到達，然后才能迎接旅客，在時間軸上要靠前些。框架里的類必須先注冊bean定義，然后才能為其它類注冊bean定義，在時間軸上同樣也要靠前些。
3、乘務員是走工作人員通道進入，旅客是正常買票/檢票進入，進入方式是不同的?？蚣芾锏念愂侵苯油ㄟ^寫代碼的方式注冊的bean定義，業務類是通過標注解的方式注冊的bean定義，注冊bean定義的方式也是不同的。
所以慢慢就會發現，任何上層封裝的很完美的代碼，當一步步到達底層時，都會進行一些“特殊”的處理。這種現象并不只是程序代碼里才有，在歷史上一直都存在。
易中天品三國中講過一個小故事，曹操領兵打仗時定了一條軍規，凡是誰的馬踐踏了農田，是要殺頭的。有一天不湊巧，曹操自己的馬驚了，跳進了農田。
曹操喊來相關負責人，問他，“按規定應該怎么處置啊”？答曰：“應該殺頭”。但這可是曹操啊，怎么能殺頭呢。于是那個人又說：“身體發膚受之于父母，我們自己沒有權力損壞”。
于是曹操就拔出劍，割下了自己的一縷頭發，扔到了地上。這就相當于受到了非常嚴重的處罰，等于死過了。這不就是特殊處理嘛。
這也說明了，跟領導混的，必須得有幾把刷子，畢竟古語道，伴君如伴虎啊。
扯得有點遠了，再回到正題。
Spring為了使bean定義的處理更加靈活，還提供了一個特殊的接口，即BeanFactoryPostProcessor接口，也就是上面那個接口的父接口：
?
當執行到這個接口的時候，所有的bean定義其實都已經注冊好了，所以這個接口的目的就是再給一次修改（或完善）bean定義的機會。
當這個接口執行完后，所有的bean定義就真的確定下來了，不會再變了。
如果對Spring不是很熟悉的，只要記住下面這個總結就行了：
這兩個接口是特殊的，它們就是用來為其它類注冊bean定義或修改已注冊好的bean定義的。
這兩個接口的實現類也會被注冊bean定義，只不過在時間軸上會非常的靠前。
這兩個接口可以有多個實現類，可以通過實現排序接口進行排序，以保證邏輯上先后順序的正確性。
其實不懂這些也無所謂，不影響成為一個合格的程序員。
bean定義上梁山
108位梁山好漢上梁山的原因和過程各不相同，但最后都到了梁山。
bean定義的注冊方式和方法也有好幾種，但最后都能注冊成功。
因為歷史已經走到了注解和Java配置的時代，所以它們就是主角了。
使用注解注冊bean定義：
標有@Component注解的類
標有@Configuration注解的類
標有@Configuration注解的類里標有@Bean注解的方法返回的類
這種方式既可以用于業務類的注冊，也可以用于Spring框架內部的類注冊。
優點是簡單方便，缺點是不夠靈活。尤其很難根據一個條件判斷來注冊不同的bean定義。
使用XML配置注冊bean定義：
在標有@Configuration注解的類上，使用@ImportResource注解引入XML配置文件。
這種方式使在注解里也能使用XML。個人覺得除非是遺留系統，否則全用注解。畢竟時代潮流不會逆轉。
使用@Import注解引入：
在標有@Configuration注解的類上，使用@Import注解引入其它標有@Configuration注解的類。
這僅用于沒有類路徑掃描功能的項目代碼，現在大都基于SpringBoot，這種方式已經用的很少了。
使用ImportSelector接口注冊bean定義：
?
接口方法返回的是類名稱的數組，這些類將會被注冊bean定義。
在實現這個接口時，可以根據不同的情況返回不同的類名稱，這就非常的靈活，實現了動態注冊bean定義的需求。
這個接口用于Spring框架內部開發，或其它框架與Spring的整合對接。
典型用法是在一個特定功能注解上使用@Import注解引入這個接口的實現類。
這個接口方法的參數importingClassMetadata是最終標有這個特定功能注解且同時標有@Configuration注解的那個類。
請參考文章末尾示例代碼。
使用ImportBeanDefinitionRegistrar接口注冊bean定義：
?
這個接口方法沒有返回值，所以需要自己寫代碼直接注冊bean定義，當然也是非常靈活的。
在用法上和上面那個接口一模一樣，包括接口方法參數的含義也一樣。
除了這種用法，還可以把這個接口的實現類的類名稱放入上面那個接口方法的返回數組中，照樣是管用的。
這個接口的目的和上面那個接口也是一樣的。
請參考文章末尾示例代碼。
使用BeanDefinitionRegistryPostProcessor接口注冊bean定義：
這在上一小節已經介紹了，屬于最基礎的方式。使用它可以做到盡早的注冊bean定義。
上面這幾種就是Spring支持的bean定義的注冊方式，有適合業務開發的，有適合Spring內置功能或其它框架與Spring整合的。
PS：隨著本系列文章走下去，慢慢就會明白其它框架是如何與Spring整合的，其實不難。
示例代碼：
https://github.com/coding-new-talking/taste-spring.git
?
>>> 品Spring系列文章 <<<
?
品Spring：帝國的基石
品Spring：bean定義上梁山
品Spring：實現bean定義時采用的“先進生產力”
品Spring：注解終于“成功上位”
品Spring：能工巧匠們對注解的“加持”
品Spring：SpringBoot和Spring到底有沒有本質的不同？
品Spring：負責bean定義注冊的兩個“排頭兵”
品Spring：SpringBoot輕松取勝bean定義注冊的“第一階段”
品Spring：SpringBoot發起bean定義注冊的“二次攻堅戰”
品Spring：注解之王@Configuration和它的一眾“小弟們”
品Spring：bean工廠后處理器的調用規則
品Spring：詳細解說bean后處理器
品Spring：對@PostConstruct和@PreDestroy注解的處理方法
品Spring：對@Resource注解的處理方法
品Spring：對@Autowired和@Value注解的處理方法
品Spring：真沒想到，三十步才能完成一個bean實例的創建
品Spring：關于@Scheduled定時任務的思考與探索，結果尷尬了
?
作者是工作超過10年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂并記住。下面是公眾號二維碼，歡迎關注！
??????
總結
以上是生活随笔為你收集整理的品Spring：bean定义上梁山的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Python中的groupby用法
- 下一篇： 在Mac上如何查看自己是否安装过jdk以