找出內存泄漏另一方法

程序有內存泄漏的第一個跡象通常是它拋出一個 OutOfMemoryError，或者因為頻繁的垃圾收集而表現出糟糕的性能。幸運的是，垃圾收集可以提供能夠用來診斷內存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 選項調用 JVM，那么每次 GC 運行時在控制臺上或者日志文件中會打印出一個診斷信息，包括它所花費的時間、當前堆使用情況以及恢復了多少內存。記錄 GC 使用情況并不具有干擾性，因此如果需要分析內存問題或者調優垃圾收集器，在生產環境中默認啟用 GC 日志是值得的。

有工具可以利用 GC 日志輸出并以圖形方式將它顯示出來，JTune 就是這樣的一種工具（請參閱 參考資料）。觀察 GC 之后堆大小的圖，可以看到程序內存使用的趨勢。對于大多數程序來說，可以將內存使用分為兩部分：baseline 使用和 current load 使用。對于服務器應用程序，baseline 使用就是應用程序在沒有任何負荷、但是已經準備好接受請求時的內存使用，current load 使用是在處理請求過程中使用的、但是在請求處理完成后會釋放的內存。只要負荷大體上是恒定的，應用程序通常會很快達到一個穩定的內存使用水平。如果在應用程序已經完成了其初始化并且負荷沒有增加的情況下，內存使用持續增加，那么程序就可能在處理前面的請求時保留了生成的對象。

圖 1 顯示  GC 之后應用程序堆大小隨著時間的變化圖。上升趨勢是存在內存泄漏的警示信號。（在真實的應用程序中，坡度不會這么大，但是在收集了足夠長時間的 GC 數據后，上升趨勢通常會表現得很明顯。）

確信有了內存泄漏后，下一步就是找出哪種對象造成了這個問題。所有內存分析器都可以生成按照對象類進行分解的堆快照。有一些很好的商業堆分析工具，但是找出內存泄漏不一定要花錢買這些工具 —— 內置的 hprof 工具也可完成這項工作。要使用 hprof 并讓它跟蹤內存使用，需要以 -Xrunhprof:heap=sites 選項調用 JVM。

清單 3 顯示分解了應用程序內存使用的 hprof 輸出的相關部分。（hprof 工具在應用程序退出時，或者用 kill -3 或在 Windows 中按 Ctrl+Break 時生成使用分解。）注意兩次快照相比，Map.Entry、Task 和 int[] 對象有了顯著增加。

請參閱 清單 3。

清單 4 展示了 hprof 輸出的另一部分，給出了 Map.Entry 對象的分配點的調用堆棧信息。這個輸出告訴我們哪些調用鏈生成了 Map.Entry 對象，并帶有一些程序分析，找出內存泄漏來源一般來說是相當容易的。

TRACE 300446:
	java.util.HashMap$Entry.<init>(<Unknown Source>:Unknown line)
	java.util.HashMap.addEntry(<Unknown Source>:Unknown line)
	java.util.HashMap.put(<Unknown Source>:Unknown line)
	java.util.Collections$SynchronizedMap.put(<Unknown Source>:Unknown line)
	com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)
	com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)