1、又見內存泄露1、首先是測試人員使用Loadrunner測試的過程中發現系統的吞吐率會隨著時間而下降，在排除了測試數據分布不均的問題在測試，發現吞吐率保持穩定的一段時間后會陡然下降，平均事務處理時間陡然上升。于是，對系統的運行進行監控，在客戶端壓力平均的時候，系統內存兩個小時內從500m上升到1G，基本上可以認定是內存泄露。1.1系統的吞吐率圖下載 (40.49 KB2009-6-21 19:041.2系統的平均事務處理時間圖下載 (33 KB2009-6-21 19:042、添加 verbose:gc啟動的參數，重新測試，發現每次Full GC后的對象空間持續緩慢增加，過了一段時間后，發現Mi

2、ner GC無法釋放空間，每次GC都是Full GC，到最后，Full GC也無法釋放出空間出來。3、安裝netbean profile對系統使用情形進行監控，發現a、堆內存的已使用空間緩慢增長，直到最大內存限制；下載 (16.74 KB2009-6-21 19:04b、接近最大內存限制的時候，內存平均對象的年齡（Surviving Generations）急劇上升，見下圖中的紅線。c、Relative Time Spendt in GC 直劇上升，分析，當GC占用的CPU大量時間，系統的吞吐率下降，和LoadRunner的測試結果是符合的。見下圖中的藍線下載 (20.95 KB2009-6-

3、21 19:044、獲取內存對象的靜態映像，發現內存中占空間最大的幾種存活對象的平均對象年齡都比較大，并且隨著時間的增長，這幾類對象占用的空間與平均對象年齡都不停的加大，見圖。下載 (42.22 KB2009-6-21 19:045、查看這幾種對象的分配時候的程序堆棧，發現這些對象是mule框架初始化組件對象的時候所創建，心中犯疑，什么促使mule框架不停的創建全局對象？int。而MuleLocalTransport對象只有在初始化的時候才會生成全局對象。繼續看代碼發現可以在XFireServiceComponent的setDescriptor打印日志來確認mule是否不停創建全局對象。6、在

4、XFireServiceComponent的關鍵初始化方法setDescriptor中添加日志，編譯、重新打包，替換原來的類。新的類每當 setDescriptor被調用一次就打印一行日志。重新測試，發現每個一段時間setDescriptor就被調用一次。由于每調用 setDescriptor一次，就會產生大量的全局對象，并且全局對象不被釋放，導致堆內存的增長。7、會讓mule如此瘋狂的原因是什么呢？詳細查看mule的配置，逐步集中到對象池與線程池的配置：發現對象池的配置maxActive=5，maxIdle=5 ，配置明顯過小，在對象池的exhaustedAction="GROW&

5、quot; 。線程池的配置maxThreadsActive明顯大于對象池的配置。這樣mule肯定會創建對象，由于 對象池的對象很快由于超過了maxActive=5，多余的對象會被釋放。8、修改該配置maxActive=50，maxIdle=50， 對象池的exhaustedAction="Wait"， 重新運行， maxThreadsActive=50 。是運行了7個小時，內存正常。9、由于 對象池的exhaustedAction="Wait"的情況下沒有內存泄露，不等于說mule沒有問題。mule放入對象池的對象是DefaultMuleProxy。為了

6、與xfire集成，對象池放入一類特殊對象：org.mule.impl.model.DefaultMuleProxy -viders.soap.xfire.XFireServiceComponent后者包含成員變量viders.soap.xfire.transport.MuleLocalTransport與 viders.soap.xfire.transport.MuleUniversalTransport在對象池釋放 DefaultMuleProxy后沒有得到釋放。從netbeans profile的內存映像上看：這兩個類的對象，生成對象的數目=存活的對象數目，一個都沒有釋放過。這兩類對象又攜帶了大量的全局對象，導致內存泄露。10、上述兩類對象為什么無法釋放？經過一番查找，發現在XFireServiceComponent的setDescriptor方法，對象被注冊到 org.codehaus.xfire.transport.DefaultTransportManager中去了，之后不見有unregister的操作。代碼如下：        getTransportManager