java内存泄露的原因

内存洩漏大家都不陌生了，那麽java内存洩露的原因是什麽呢?下面是生活日記小編精心爲你整理的java内存洩露的原因，一起來看看。

java内存洩露的原因

java内存洩露典型特征

現象一：堆/Perm 區不斷增長, 沒有下降趨勢(回收速度趕不上增長速度), 最後不斷觸發FullGC, 甚至crash(如下兩張圖是同一個應用的GC和Perm數據, GC觸發原因确認是Perm不足). 一般是現象二的晚期表現。

現象二：每次FullGC後, 堆/Perm 區在慢慢的增長, 最後不斷觸發FullGC, 甚至crash。

java内存洩露場景---PermGen space

原因：說明Perm不足. Perm存放class,method相關對象，以及運行時常量對象. 如果一個應用加載了大量的class, 那麽Perm區存儲的信息一般會比較大.另外大量的intern String對象也會導緻Perm區不斷增長。 此區域大小由-XX:MaxPermSize參數進行設置.

案例： Groovy動态編譯class, xstream String.intern

本質原因：ClassLoader.defineClass和java.lang.String.intern在大量不适宜的場景被調用.

解決方案：

方案1(直接有效): 使用btrace相關工具輸出調用ClassLoader.defineClass棧信息, 從棧信息來追溯問題.

用JProfiler來trace String.intern方法棧

方案2: dump heap, 看看哪些class有異常現象(數量), String被Perm區引用的對象信息等.但這種方式不太直觀，可以從String數據看看發現可疑問題，沒有方案1直觀。(如下圖: 如果能在日常調試推薦JProfiler)

方案3: 增加-XX: TraceClassLoading和-XX: TraceClassUnloading, 看看哪些class加載了，哪些class卸載了. 如果一些特殊的class一直被加載而沒有被卸載說明也是有問題的。

方案4：執行jmap -permgen(jstat -gcutil 可以查看内存增長速度和區域)命令看看Perm區中的内容, 初步确定是否存在問題 。

java内存洩露場景---Java heap space

原因：長生命周期的對象引用了短生命周期(應該盡快GC回收掉)的對象，最後

[!--empirenews.page--]

後造成一個對象已經不能在堆區分配足夠空間. 注: 這種現象不能完全肯定是内存洩露, 比如: heap本身的設置的過小.

案例： 我個人沒有遇到過這種案例, 但模拟過這種情形的Demo: 參考我的《深入淺出JProfiler》文章, 也學習過其他同學的案例: 例如:參數過大并且頻繁超時導緻内存洩露

解決方案：

觸發FullGC, dump live heap. 标記堆中對象數量, 重點關注可疑對象

觸發FullGC, dump live heap. 标記堆中對象數量, 重點關注可疑對象

對比步驟1和步驟2 相同對象的數量和大小, 找出可疑對象一一進行排查确認。

如果步驟3依然無法明确有問題的對象, 那就多執行幾次步驟1和步驟2。在此過程中可以調整GC觸發時間, 模拟真實的故障場景

看看GC後堆的大小是否增長, 如果沒有不斷增長, 并且持續一段較長時間, 那基本正常(具體看看。

java内存洩露怎麽辦

縮小問題的範圍

要找出内存洩漏的原因當下已經有許多工具可用，比如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中的數據則改爲存儲在本地内存或者棧中。