【編者按】作者Martin Gutenbrunner供職於Ruxit，擁有十年的Java Web應用程序架構和管理經驗。近日，他在Dzone上撰文分享了Java內存洩漏識別相關經驗，由OneAPM工程師翻譯。
以下為譯文
Java開發人員都知道，Java利用垃圾回收機制來自動保持應用程序內存的干淨和健康。然而可能有人不知道的是，即使使用了垃圾回收機制，Java中仍然可能存在內存洩漏風險。如果你碰到下面的錯誤代碼：
java.lang.OutOfMemoryError: Java heap space
如果你確認是內存分配不足，那麼可以通過以下代碼為應用程序增加可用內存：
java -Xms<initial heap size> -Xmx<maximum heap size>
不過對於內存洩漏來說這麼做是治標不治本，只能起到緩解作用。
內存洩漏的識別
在將程序部署到生產環境之前檢查一下是否存在內存洩漏的問題是很有必要的。這裡可以通過垃圾收集器的指標來進行初步的判斷。
如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中的數據則改為存儲在本地內存或者棧中。
原文鏈接：Memory Problems: How to Identify a Java Memory Leak（責編/仲浩）