認真閱讀，收穫滿滿，向智慧又邁進一步。。。 技術不枯燥，先來點閑聊先說點好事高興一下。前段時間看新聞說，我國正式的空間站建設已在進行當中。下半年，長征五號B運載火箭將在海南文昌航天發射場擇機將空間站核心艙發射升空。預計用2到3年將空間站建好。雖然到時你們不讓我上去，不過我也為這件事出不了什麼力，算扯 ...
認真閱讀，收穫滿滿，向智慧又邁進一步。。。
技術不枯燥，先來點閑聊
先說點好事高興一下。前段時間看新聞說，我國正式的空間站建設已在進行當中。下半年，長征五號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介面：
public interface BeanDefinitionRegistryPostProcessor extends BeanFactoryPostProcessor {
void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException;
}
介面只有一個方法，就是註冊bean定義。
這個介面有一個非常重要的實現類，即ConfigurationClassPostProcessor類，它裡面包含了所有Spring支持的註冊bean定義方式的實現。
因Spring統一了編程模型，所以這個類也被註冊了bean定義。又因為這個bean只有運行起來後才可以為其它類註冊bean定義，所有這個類無論是註冊bean定義還是運行，在時間軸上都是比較靠前的。
事實上，它是Spring註冊的第一個bean定義，bean的類就是剛纔提到的那個實現類，bean的名稱是：
org.springframework.context.annotation.internalConfigurationAnnotationProcessor
說白了這個類就是用來處理那些使用註解標註的類，為它們註冊bean定義的。所以這個類它自己的bean定義註冊絕對不能再使用註解的方式，而是使用代碼直接註冊的，可以認為是寫死的。
通過高鐵乘務員和旅客的這種情況，可能會理解的更明白些。
1、乘務員是人，旅客也是人，他們都是人。框架里的類註冊bean定義，業務類註冊bean定義，它們都註冊bean定義。
2、乘務員必須先到達，然後才能迎接旅客，在時間軸上要靠前些。框架里的類必須先註冊bean定義，然後才能為其它類註冊bean定義，在時間軸上同樣也要靠前些。
3、乘務員是走工作人員通道進入，旅客是正常買票/檢票進入，進入方式是不同的。框架里的類是直接通過寫代碼的方式註冊的bean定義，業務類是通過標註解的方式註冊的bean定義，註冊bean定義的方式也是不同的。
所以慢慢就會發現，任何上層封裝的很完美的代碼，當一步步到達底層時，都會進行一些“特殊”的處理。這種現象並不只是程式代碼里才有，在歷史上一直都存在。
易中天品三國中講過一個小故事，曹操領兵打仗時定了一條軍規，凡是誰的馬踐踏了農田，是要殺頭的。有一天不湊巧，曹操自己的馬驚了，跳進了農田。
曹操喊來相關負責人，問他，“按規定應該怎麼處置啊”？答曰：“應該殺頭”。但這可是曹操啊，怎麼能殺頭呢。於是那個人又說：“身體髮膚受之於父母，我們自己沒有權力損壞”。
於是曹操就拔出劍，割下了自己的一縷頭髮，扔到了地上。這就相當於受到了非常嚴重的處罰，等於死過了。這不就是特殊處理嘛。
這也說明瞭，跟領導混的，必須得有幾把刷子，畢竟古語道，伴君如伴虎啊。
扯得有點遠了，再回到正題。
Spring為了使bean定義的處理更加靈活，還提供了一個特殊的介面，即BeanFactoryPostProcessor介面，也就是上面那個介面的父介面：
public interface BeanFactoryPostProcessor {
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
當執行到這個介面的時候，所有的bean定義其實都已經註冊好了，所以這個介面的目的就是再給一次修改（或完善）bean定義的機會。
當這個介面執行完後，所有的bean定義就真的確定下來了，不會再變了。
如果對Spring不是很熟悉的，只要記住下麵這個總結就行了：
這兩個介面是特殊的，它們就是用來為其它類註冊bean定義或修改已註冊好的bean定義的。
這兩個介面的實現類也會被註冊bean定義，只不過在時間軸上會非常的靠前。
這兩個介面可以有多個實現類，可以通過實現排序介面進行排序，以保證邏輯上先後順序的正確性。
其實不懂這些也無所謂，不影響成為一個合格的程式員。
bean定義上梁山
108位梁山好漢上梁山的原因和過程各不相同，但最後都到了梁山。
bean定義的註冊方式和方法也有好幾種，但最後都能註冊成功。
因為歷史已經走到了註解和Java配置的時代，所以它們就是主角了。
使用註解註冊bean定義：
