Java開發人員都知道，Java利用垃圾回收機制來自動保持應用程序內存的乾淨和健康。然而可能有人不知道的是，即使使用了垃圾回收機制，Java中仍然可能存在內存泄漏風險。如果你碰到下面的錯誤代碼：
如果你確認是內存分配不足，那麼可以通過以下代碼爲應用程序增加可用內存：
不過對於內存泄漏來說這麼做是治標不治本，只能起到緩解作用。
內存泄漏的識別
在將程序部署到生產環境之前檢查一下是否存在內存泄漏的問題是很有必要的。這裏可以通過垃圾收集器的指標來進行初步的判斷。
如GC後內存使用仍然持續上升，那麼就可能有內存泄漏的問題，比如上面的這幅圖，代碼可以查看GitHub。不過在現實中內存像圖上一樣線性增加的可能性是很小的，見圖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中的數據則改爲存儲在本地內存或者棧中。
