共計 943 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關如何識別 Java 中的內存泄漏，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

內存泄漏的識別

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

如 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 中的數據則改為存儲在本地內存或者棧中。

關于如何識別 Java 中的內存泄漏就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。