如何識別Java中的記憶體洩漏

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中的資料則改為儲存在本地記憶體或者棧中。