前段時間研究了下dbcp的一些源碼，發現dbcp對common pools依賴比較嚴重，基本就是基于pool的擴充接口實作的。是以也就順便看了下pools的源碼。
common pools的代碼總體結構來說是比較簡單的。
先上一個類圖：
objectpool 對象池
objectpoolfactory 池的維護工廠
poolableobjectfactory 可池化對象的維護工廠
keyedobjectpool 基于kety的對象池
keyedobjectpoolfactory
keyedpoolableobjectfactory
說明： objectpool和keyedobjectpool基本接口都是一緻的，唯一不同的就是keyedobjectpool是基于key做為鍵值，其對應的存儲結構就是 map<object , list<object>>， 每次根據key定位list<objct>的value後，再進行池化管理。
1. genericobjectpool： 通用的對象池處理類，維護池的大小，空閑連結等等。 針對對象的makeobject,destoryobject等都是委托給poolableobjectfactory進行處理。
基本參數和dbcp的配置參數一樣，可以參考： http://agapple.iteye.com/admin/blogs/772507
關注幾個特别的參數：
_lifo : 采用的清單管理模式，采用先進先出or後進先出。 預設是先進先出，底層具體的池對象儲存是通過cursorablelinkedlist。
_softminevictableidletimemillis : 軟性idle空閑管理。預設是-1。 相比于_minevictableidletimemillis，系統預設優先處理_minevictableidletimemillis空閑管理機制，除此主要的差別就是處理空閑連結時，soft會考慮目前的池大小是否滿足 > minidle數。
_timebetweenevictionrunsmillis ： evict管理線程的運作時間，預設-1。也就是說預設不運作，注意如果要使用idle空閑管理必須設定該值，否則沒效果。
2. stackobjectpool : 基于stack堆棧概念的對象池，對象池的borrow或者return都是符合stack的先進先出彈棧的管理，相比于genericobjectpool，它隻有maxidle(最大空閑數), maxtotal(最大資源數)管理，暫時還未想到特定的應用場景，因為覺得genericobjectpool的功能基本可以覆寫stackobjectpool，隻要适當的調整參數。
3. softreferenceobjectpool : 看名字就應該猜到是基于softreference進行對象持有的pool，在記憶體不足時可以主動的釋放pool object對象, 通過referencequeue擷取object對象需要被清除的時間點。至于softreference可以看下了解 java 的 gc 與 幽靈引用
4. generickeyedobjectpool： 差別于genericobjectpool，主要是該pool池，針對每個資源都有自己特定的域，就是一個對應的key。每個key下可以有一組object。 maxtotal是針對所有的key下的object之和，而非單個。
首先以dbcp為例,介紹其相關擴充點。
說明：
1. dbcp整個連接配接池的管理是使用genericobjectpool
2. dbcp這裡通過擴充實作自定義的poolableobjectfactory ， 用于定義如何建立/銷毀/校驗一個datasource等。
3. 使用的statement cache利用的是generickeyedobjectpool，因為statement cache是基于key進行statement管理的，是以比較适合。但目前在使用statement cache會出現一些異常情況，慎用。
4. poolingconnection實作了statement cache對應池對象的建立/銷毀。 同時在datasource的執行close，同時需要清理整個statement cache pool的close動作，避免出現資源洩漏。
實作一個memcache client的連接配接池代碼
1. 實作一個poolableobjectfactory接口，提供建立/銷毀/校驗的方法
2. 建立socketpool類，用于管理pool
3. 用戶端端使用
使用common-pools後，實作一個自己的連接配接池也是相對比較單了