先啟動Optimizeit Suite中的profiler模塊：
圖5 啟動Profiler模塊
圖6 在Profiler主界面中添加新Setting
注意使用Borland Optimizeit Suite時，jar中要把main class設好，classpath中要把所有用到的外部jar包全部輸入，否則無法啟動和正常運行。這個工具不太友好，無法啟動時輸出信息很不明確，所以最好自己先檢查清楚了。
圖7 在Profiler的Setting中設置main class和classpath
一般測試時都有運行多次，當發現某些包跟問題無關時，可以把它們過濾掉，這樣最后得到的結果更容易閱讀。
圖8 設置filter
用Profiler啟動程序。運行到問題模塊后，點擊工具欄最右邊的按鈕，標記當時各對象占用內存的情況。
圖9 標記當前內存情況（圖中紅柱上的黑線）
點擊工具欄上像感嘆號的按鈕，選擇顯示的內容。對這個問題，我覺得show size是最重要的。
圖10 設置顯示的內容
再運行一段時間后，按Size diff排序。發現占用內存比較多的了后，雙擊該行，打開該對象的詳細信息（目前bug已經改好，我只是隨便點一個類作為示范）。這時展開整棵樹，就可以看到該類所有實例分別是在什么方法中生成的（如果跟蹤CPU信息，也有這種資源分配樹顯示）。
圖11 某個類的所有對象的構造位置分布
因為占用內存最多的往往是系統基本數據類型，例如char，int[]等等，所以需要人工去判斷哪些類是真正的疑點。我發現占用新申請內存排名第20－30之間有幾個類的對象數是完全相同的，而且持續同步增長，估計是某些線程中重復構造對象造成的，比其他以不規則速度增長的類更加可疑，于是就仔細檢查了這幾個的類的詳細信息，發現果然是來自同一個函數。再仔細看代碼，就找到內存泄漏的原因，原來是某行代碼寫錯了，不斷構造新的button。而保存這些button是用Vector！說明我最早使用的檢查HashMap的思路是對的�？上е皇菑淖约旱木幊塘晳T出發，沒有考慮到Vector，否則問題就更容易發現了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
