如何識別Java中的內存泄漏

內存泄漏的識別

在將程序部署到生產環境以前檢查一下是否存在內存泄漏的問題是頗有必要的。這裏能夠經過垃圾收集器的指標來進行初步的判斷。

如GC後內存使用仍然持續上升，那麼就可能有內存泄漏的問題，好比上面的這幅圖，代碼能夠查看GitHub(https://gist.github.com/dpryden/b2bb29ee2d146901b4ae)。不過在現實中內存像圖上同樣線性增長的可能性是很小的，見圖Old Gen，而GC suspension times或者Eden Space和Survivor空間使用並不足以識別出內存泄漏。

縮小問題的範圍

要找出內存泄漏的緣由當下已經有許多工具可用，好比JVisualVM或者jStat。這些工具是JDK自帶的，因此你們隨時都能用。除了要識別一些經常使用的內部Java類，一些用戶自定義累一樣須要識別。

性能優化

在平常的開發過程當中，只要GC沒有影響到性能，開發者就不會去關注內存設置於配置。從而埋下了潛在的隱患：由於內存問題並不僅有溢出和泄露，GC時間過長一樣會形成這個問題。好比下圖中GC佔用了16%的CPU。

Heap設置

Heap過小會致使頻繁的GC，從而情景不難想象：增長GC會消耗更多的CPU，同時在GC時JVM會被凍結，最後致使一個不好的性能。總的來講，Heap過小的話，雖然GC時間變短，可是會變得更加頻繁。

Heap太大會致使GC時間邊長。GC不會常常發生，可是一旦被觸發，那麼VM會被凍結好久。

所以，若是這種狀況下發生內存泄露，在最終JVM由於內存溢出崩潰以前，GC會很是頻繁或者時間特別長。

GC版本

從Java 6開始，GC就改變了不少。Java 7引入了G1GC做爲CMS GC的替代選擇，而在Java 9中G1GC已成爲默認選擇。Java 8中移除了PermGen Space，以前存儲在PermGen Space中的數據則改成存儲在本地內存或者棧中。