Java語言相比C++的一個很大優勢就是Java可以自動管理內存的回收，在軟件測試工作中這大大減少了程序員的負擔。然而，Java并不是杜絕了所有的內存問題，還是會有內存泄漏的問題，只不過原因和C++是不一樣的，所以出現得比較少。Java的內存垃圾回收機制是從程序的主要運行對象開始檢查引用鏈，當遍歷一遍后發現沒有被引用的孤立對象就作為垃圾回收。在現在代碼檢查工具越來越先進的情況下，C++的內存漏洞檢查已經變得容易很多，但Java的內存漏洞由于機制不一樣，反而無法通過工具直接檢查出來，只要靠輔助工具檢測，發現疑點，然后再手動解決。
下面是我調試一個大型軟件系統內存泄漏問題的過程，把其中失敗的做法也寫出來了，因為都是有參考價值的：
現象：程序啟動后一直運行正常，但啟動某個模塊后，每分鐘多消耗1M的內存，持續增長到出現java.lang.OutOfMemoryError為止，而CPU占用率也是逐步上升至100%。
判斷：由于CPU和內存都出現問題，無法判斷哪個是主因，也可能是多個原因造成的，估計最可能是多線程或者內存泄漏的問題。
輔助工具：由于不是我自己寫的程序，所以沒法直接估計是代碼的哪一部分的問題，所以需要使用輔助工具，我比較常用的是Eclipse的插件ru.nlmk.eclipse.plugins.profiler（免費）和Borland公司的Borland Optimizeit Suite（收費）。因為我是用Eclipse來開發程序，所以使用前者比較方便，個人感覺使用時占用的系統資源少一點，而且在CPU檢查方面是略強一點，但是后者在內存檢查方面強大很多。
分析過程：當時由于CPU和內存都出現問題，無法判斷哪個是主因，需要檢測兩方面的數據。內存泄漏需要等程序運行一段時間后才能看出來，所以檢查很消耗時間。為了減少干擾，我把系統中所有不是必要的各線程逐個關閉來試驗，然后把確認對內存問題沒有影響的線程都關閉。
首先考慮解決內存問題。因為Java的內存泄漏問題往往跟HashMap相關，所以HashMap可能是一個突破口，而這么大量的內存泄漏，很可能會是某些HashMap存放過多已經沒用的對象造成的（如果是這個原因，那改為用WeakHashMap就可以解決問題了）。我從HashMap和LinkedHashMap派生了子類，其中加入了數據量檢查的信息，把系統中所有構造HashMap和LinkedHashMap的地方都改為使用這些子類。但是運行后發現系統中構造的HashMap只有十幾個，而且每個指向的對象也不多，只有少數幾個是接近1千的，而仔細檢查代碼后，發現這幾個指向對象較多的HashMap也不會造成太大的內存泄漏問題。
這樣我的思路就中斷了，只好求助于工具來尋找疑點。因為發現CPU占用到100％一段時間后，程序就呈死機狀態沒法運行下去了，內存問題也就無從檢測，所以就決定先檢查CPU，用Eclipse的profiler插件來查。如圖：
圖1 Eclipse的profiler插件的Threads View
文章來源于領測軟件測試網 http://www.kjueaiud.com/
