1、做一個自己的 AppServer JDStream( )構想一直以來總是有一種緊迫感，想盡力去彌補那些逝去的歲月。可是知識可以積累，經驗就沒那么容易積累了，另外人都有惰性，上班的時間可以十分投入，一旦下班往往就沒了狀態。所以我總是給自己業余時間定個目標， 有了目標，就有了方向，就可以逼迫自己坐下來去深 入技術，再慢慢進入狀態，形成良性循環。最開始給自己定的幾個目標都沒能堅持下來，一方面是那時自己很多技術確實沒有太多概念，另外與工作也基本無關，所以研究了一段時間后也就不了了之了。就在多半年前深入了解了下公司的一個底層RPC框架，主要就是一個包括數據庫連接池、模塊池、類似 mina的socket模

2、塊、rmi同步和異步調用這些功能的開發包。在使用中發 現該框架存在不少問題， 遠程調用比較麻煩， 沒有一個統一的調用接口，同時和業務程序耦合比較嚴重，每次都要寫啟動程序。于是就稍稍去研究了下JBoss，將公司的Jar包做了進一步包裝，寫成服務器的形式，自定義了ClassLoader來加載業務程序，用動態代理統一了遠程調用接口，自己寫了個Annotation 解析器來解析業務程序中自己定義的注釋。這些完成后是比原來方便了些，但隨著對AppServer研究的深入，發現現有框架仍有非常多的不足，不是修修補補就能解決的了，于是就決定重新寫一個AppServer。目的不在于能否寫一個多牛的服務器，而是給

3、自己定一個目標，來研究這些技術，希望通過這個能使自己的技術提升一個高度，同時附帶著做一個自己用著順手并且可以完全控制的AppServer出來。用了將近一個月的時間囫圇吞棗的讀完了JBoss架構分析，同時粗略的閱讀了JBoss4和JBoss5的啟動源代碼，對 AppServer的實現有了個具體的概念，發現自己以前項目中 的應用程序完全可以掛在 JBoss下面，但現在的目標是寫一個相對輕量級的、可以自己控 制的、以IOC為容器而非JMX為容器的、偏重與處理業務數據流的支持高并發的AppServer 。出于偏重于數據流處理的需要，所以準備暫時將之名稱定為JDStream(JAVADataStream

4、 )。做一個自己的 AppServer JDStream(二)選型 文章分類 :Java 編程關鍵字 :appserver 服務器分布式JBoss4 及其以前的版本主要是用 JMX 做為系統總線來管理插件， 好處是顯而易 見的，可是隨著 IOC 的發展， JMX 作為容器插件也有很多不足， 比如 JMX 作為 容器過于復雜，與業務程序耦合過多，不夠POJO,所以JB0SS5有所改進，它用 JBossMicrocontainer 作為 IOC 插件容器，同時通過 JMXKernel 將 JBoss4 的內核連接進來，把本屬于 JMX 管理的 bean 的生命周期委托給 Micr0c0ntaine

5、r 管理，但由于 JB0SS 過于龐大，并沒有從根本上解決問題， Micr0c0ntainer 雖然從內在上管理了 Bean 的生命周期，但很多插件外殼還是 由 JMX 來管理的，需要構建 mbean ，和 Jb0SS 過于耦合。所以 JDStream 采用 IOC 完全管理插件，但又不像 Spring 那樣托管所有 Bean ， 它只需要管理插件入口的 Bean ，方便拆卸同時又不會產生很多煩人的配置，另 外還需要管理業務代碼中的一些 Bean。JMX作為插件和業務模塊的配置和監控 容器，盡量減少它的使用。由此 IOC 框架和 JMX 實現作為兩個最基礎的框架需要優先考慮，此次構建 JDSt

6、ream 的最大目的在于磨練技術，不需要一切從頭來，這兩個框架都采用開 源的，在需要的時候對他們進行擴展甚至修改。IOC 框架可供選擇的大概有下面幾個： Spring 、Jb0SSMicr0C0ntainer 、 Pic0C0ntainer 和 JF0x。Spring 過于龐大，更適合做外層框架，不太適合將它集成到別的程序里面； JB0SSMicr0C0ntainer 從使用上來說是個比較不錯的 IOC 容器，輕量且有多級 生命周期策略，控制比較細致，但作為單獨的 IOC 容器，在 06 年的時候已經停 止開發維護了， JBoss5 嵌入的 MicroContainer 在原先的基礎上有了很大

7、的擴 展，同時和 JBoss5 的程序耦合在了一起，很難分離出來，所以不太合適；JFox的IOC容器同樣和框架耦合在了一起，同時也過于簡單，用起來可能要做很多擴展；PicoContainer 短小精悍，生命周期雖然只有 start 、stop 和 dispose ，但基本 夠用，如真不夠使用可隨時擴展，最新的版本增加了 monitor ，可實現對 bean 的監控，唯一問題是它沒有 XML 解析器；綜上所述，決定采用 PicoContainer 作為 IOC 容器， XML 解析器自己寫。JMX實現比較了 JBoss的實現、JFox實現和MX4J后決定用MX4J，這個主要 是前兩個很多實現是為

8、自己的框架定做的，而 MX4J 作為一個獨立的 JMX 實現 比較符合需要。兩個基礎框架定下來后下面就是要集成的插件了：JNDI ：自己實現，以便于集群；AOP :自己用動態代理和CGLib寫個簡單點的；數據源模塊：自己封裝JDBC，支持事務；socket :集成 mina ；JMS :用JCA集成Activemq，支持事務；Webservice ：集成 axis2 或 xfire ，沒想好呢；cache ：集成 memcachedjava 客戶端和 BerkeleyDBjava 版；任務調度：集成 quartz ；rmi ：修改公司的 rmi 異步調用框架，提供同步和異步 RMI 工廠，支持

9、 JRMP和 IIOP；監控：集成tel net監控，通過tel net來和JDStream交互，了解服務器運行狀況；httpServer:集成 tomcat 或 jetty ；camel :還沒了解太清除，有可能的話也集成；集群：用 JGroups，關聯到 JNDI、socket、JMS、webService、cache 和 rmi插件，也是個基礎插件；線程池：鑒于業務模塊的熱部署，線程將被集中管理；業務模塊部署器：實現業務模塊的動態加載，Annotation 解析；Annotation 解析器：支持自定義 Annotation 。其它：有可能的話加上安全和事務方面的；做一個自己的 AppS

10、erver JDStream（三）IOC容器文章分類:Java編程關鍵字:appserver服務器分布式Guice 和 PicoCo nta in er的比較感謝mineral在此系列博客的上一篇當中推薦的IOC容器Guice，沒來得及看 源碼，初步了解了一下，發現 Guice確實有自己的獨到之處，它和 Spring的最 大區別應該是構造夠輕量，設計夠巧妙，配置夠簡單，但它也有很多自己的不足（個人觀點）。上一篇博客站在 JDStream使用的角度簡單的比較了 Spring、JBossMicroCo ntain er 、PicoCo nta in er 和 JFox 優缺點，決定采用PicoCo

11、ntainer 作為JDStream 的IOC容器。由于以前沒有接觸過 Guice，今 天看了些介紹后就 Guice 和 PicoContainer 做個比較，不足之處希望能得到各 位大俠的指教。1、Guice 有三種注入方式： Field 、contructor 和 setter ；PicoContainer 同樣 也有這三種注入方式；2、Guice 使用 Inject 注釋根據業務接口來注入 Bean ，如此減少了 XML 配置的 繁雜，同時又不像其它 IOC 的 Annotation 注入那樣繁瑣， 任何 Bean 的注入只 需 Inject 即可。但對于一個業務接口有多個實現的情況，

12、單憑接口并不能夠定 位到相應的 Bean ， Guice 需要以下輔助配置來定位：A :通過在業務接口上添加 lmplementedBy 注釋來指定實現類；B:通過實現Module接口硬編碼，將實現類綁定到接口，同時用自定義Annotation 來作為分支標記或自定義一個字符串作為分支標記；C:可以在lnject的下面用Name來指定實現類；同時 Guice 還可以通過實現 Provider 接口來動態注入注入；而 PicoContainer 也可以通過 lnject 注入，對于一個接口或超類多個子類的情 況也是通過自定義 Annotation 來區分；3、其它方面 PicoContainer

13、 有 Bean 的監視器、生命周期管理、 Container 父 子級聯等實現， Guice 可能也有這方面的實現，沒有做深入的研究4、Guice 有更多的注釋，同時又分綁定作用域，這個和 PicoContainer 的父子 級聯比較相似，都是實現實例的分割，相當于全局變量和局部變量。而PicoContainer 只有 Inject 、Bind 、Cache 三個注釋，并且都不帶參數； 由上面的比較基本可以看出 PicoContainer 有點像 Guice 的精簡版，它更多的 是通過 Container 接口將功能暴露給使用者，在外層并沒有做太多的封裝，它 比 Guice 更輕量，更適合嵌入

14、其它容器框架。而 Guice 更適合獨立作為一個輕 量的 IOC 框架存在。另外從 JDStream 的需求來看 PicoContainer 也更適合被 集成于其中，具體原因后面闡述。IOC 容器的原理比較了上面兩個 IOC 容器后再看 IOC 容器的原理：IOC 容器其實就是將一個類拆分了后和需要注入的參數及配置的操作緩存起來， 大部分的 IOC 容器都逃不出以下幾步：1、根據配置文件找到類名稱，用加載器加載；2、用反射從類中分離出 Field,Constructor,Method,Annotation,Interface,SuperClass 等等分類緩存；3、緩存需要注入的參數；4、根據

15、配置文件配置的操作或其它程序的調用，用 Constructor 生成 Object ， 注入參數，此實例或緩存，或不緩存，或用弱引用緩存；5、生命周期操作， Annotation 操作； 從原理上說 IOC 容器和 JMX 實現沒有太大的區別， JMX 其實也算是一種 IOC 容器。但從實現上來說IOC容器比JMX靈活的多，它不必考慮J2EE規范的限 制，完全自由發揮，可以設計的如 Spring 般繁雜，也可以設計的如 PicoContainer 般小巧。它可以使自己管理的 Bean 更加 POJO ，不必再親自去 實現框架管理接口， 而是由框架生成被管理 Bean 的子類或業務接口的實現類作

16、 為代理去實現管理接口， 然后一切業務調用都從代理接口傳入， 再去完成被管理 Bean的調用。Spring和EJB就是這樣管理的。這中間可以注冊監視器來監控 Bean 的任何狀態變化，注冊攔截器來監控外部對 Bean 的操作。IOC 容器給人的最大好處就是靈活多變， 耦合松散，但這樣的結果也是有代價的， 首先越靈活配置越復雜，大量的 XML 和 Annotation 也會成為災難，其次大量 的動態代理、反射、CGLIB、攔截器、監視器等管理手段的使用，極大的降低了 效率，對高并發環境下的應用是不可以接受的。 JDStream 的一個最重要的設計 準則是在高并發通路上盡量避免使用以反射為基礎的操

17、作，以此來提高效率。由于 JDStream 偏向于高并發處理能力的需要， 對上面的優缺點做了平衡， 那就 是插件的入口 Bean 類和插件內部的某些 Bean 類（需要對其管理但又不在高并 發通路上的） 以及業務程序里面的一些 Bean 類（同樣需要對其管理但又不在高 并發通路上的）使用 IOC 容器管理，需要對配置文件熱修改以及對內部監控提 供視圖的 Bean 類用 JMX 容器管理，其它的 Bean 類并不提供框架管理功能。JDStream 的 IOC 容器實現現在說說為什么 PicoContainer 更適合 JDStream 。首先 JDStream 的 IOC 容器最主要的職責是管理

18、插件入口的 Bean 類，這些 Bean 的相互依賴不多，而且 都肩負著插件配置參數的輸入（如 IP 地址、端口號等），這些參數在部署后要 經常修改，不可能采用 Annotation 注入，也不可能硬編碼注入，只能用 XML 注入，所以 Guice 的 Annotation 就用不上了；其次 JDStream 的另一個職責 是管理業務模塊的一些 Bean ，這些 Bean 上面將標注屬于 JDStream 自己的 Annotation ，這些 Annotation 的解析應該放在 Bean 的注冊過程中，因此擴 充 PicoContainer 更好一點；再次 Guice 管理的 Bean 基本

19、上都要實現接口， 這點和框架有點耦合； 最后最重要的一點是 PicoContainer 的 XML 解析器已經 完成了大部分了，目前先這樣寫下去，以后發覺不恰當的話在更換。上面的比較說明， 就是對 JDStream 的 IOC 容器的基本要求。 首先從 XML 解析 開始，由于配置文檔不大，所以采用 Dom4j 的 dom 方式解析配置文件。為了 做到與框架完全無關， 就不能實現框架的任何接口， 但 PicoContainer 管理 Bean 的生命周期又必須實現生命周期接口， 這樣就需要像上面說的那么樣框架生成一 個代理。代理有兩種生成方式：動態代理和CGLIB,動態代理要求被管理的Bean

20、 必須有接口實現，此處似乎對被管理的 Bean 要求多了點，所以考慮用 CGLIB 生成被管理 Bean 的子類, 同時這個子類實現框架的生命周期接口, 然后以無參 數的構造方法生成實例來作為代理 （此處要求被管理的 Bean 必須提供無參數的 構造方法）,然后以 XML 配置文件中配置的 Bean 的名稱為注冊名注冊到 PicoContainer 中,實際要注冊的 Bean 按配置文件構造實例,注入參數,以配 置的 Bean 名稱加一固定字符串注冊到 PicoContainer 中。當框架調用代理的生命周期接口時，代理委托給配置文件中定義 Bean的相應的生命周期方法，當業務程序調用代理的業

21、務方法時，代理委托給Bean的相同名稱和參數的方法。遇到的問題當業務程序調用代理的業務方法時，代理委托給Bean的相同名稱和參數的方法這個地方出現了問題，由于上面委托給Bean的方法是攔截所得，只知道實例、方法和參數，在Bean中有多個同名的重載方法時，可能無發判斷到底調用哪一 個方法。看如下代碼：Java代碼X1. publicclassTest2. publicstaticvoidma in( Stri ngargs)3. Testtest=n ewTest();4. Test1test13=newTest3();5. Test3test3=n ewTest3();6. Test4test4=newTest4();7. (1)8. test.tst(test3,test4);9. /(2)10. test.tst(test13,test