物件池化技術

物件池化的基本思路是：將用過的物件儲存起來，等下一次需要這種物件的時候，再拿出來重複使用，從而在一定程度上減少頻繁建立物件所造成的開銷。用於充當儲存物件的「容器」的物件，被稱為「物件池」（object pool，或簡稱pool）。

對於沒有狀態的物件（例如string），在重複使用之前，無需進行任何處理；對於有狀態的物件（例如stringbuffer），在重複使用之前，就需要把它們恢復到等同於剛剛生成時的狀態。由於條件的限制，恢復某個物件的狀態的操作不可能實現了的話，就得把這個物件拋棄，改用新建立的例項了。

並非所有物件都適合拿來池化——因為維護物件池也要造成一定開銷。對生成時開銷不大的物件進行池化，反而可能會出現「維護物件池的開銷」大於「生成新物件的開銷」，從而使效能降低的情況。但是對於生成時開銷可觀的物件，池化技術就是提高效能的有效策略了。

什麼時候不要池化

採用物件池化的本意，是要通過減少物件生成的次數，減少花在物件初始化上面的開銷，從而提高整體的效能。然而池化處理本身也要付出代價，因此，並非任何情況下都適合採用物件池化。

對於類似point這樣的輕量級物件，進行池化處理後，效能反而下降，因此不宜池化；

對於類似hashtable這樣的中量級物件，進行池化處理後，效能基本不變，一般不必池化（池化會使**變複雜，增大維護的難度）；

對於類似jpanel這樣的重量級物件，進行池化處理後，效能有所上公升，可以考慮池化。

根據使用方法的不同，實際的情況可能與這一測量結果略有出入。在配置較高的機器和技術較強的虛擬機器上，不宜池化的物件的範圍可能會更大。不過，對於像網路和資料庫連線這類重量級的物件來說，目前還是有池化的必要。

基本上，只在重複生成某種物件的操作成為影響效能的關鍵因素的時候，才適合進行物件池化。如果進行池化所能帶來的效能提高並不重要的話，還是不採用物件池化技術，以保持**的簡明，而使用更好的硬體和更棒的虛擬機器來提高效能為佳。