內(nèi)存泄漏大家都不陌生了，那么java內(nèi)存泄露的原因是什么呢?下面是學(xué)習(xí)啦小編精心為你整理的java內(nèi)存泄露的原因，一起來(lái)看看。

　　java內(nèi)存泄露的原因

　　java內(nèi)存泄露典型特征

　　現(xiàn)象一：堆/Perm 區(qū)不斷增長(zhǎng), 沒有下降趨勢(shì)(回收速度趕不上增長(zhǎng)速度), 最后不斷觸發(fā)FullGC, 甚至crash(如下兩張圖是同一個(gè)應(yīng)用的GC和Perm數(shù)據(jù), GC觸發(fā)原因確認(rèn)是Perm不足). 一般是現(xiàn)象二的晚期表現(xiàn)。

　　現(xiàn)象二：每次FullGC后, 堆/Perm 區(qū)在慢慢的增長(zhǎng), 最后不斷觸發(fā)FullGC, 甚至crash。

　　java內(nèi)存泄露場(chǎng)景---PermGen space

　　原因：說(shuō)明Perm不足. Perm存放class,method相關(guān)對(duì)象，以及運(yùn)行時(shí)常量對(duì)象. 如果一個(gè)應(yīng)用加載了大量的class, 那么Perm區(qū)存儲(chǔ)的信息一般會(huì)比較大.另外大量的intern String對(duì)象也會(huì)導(dǎo)致Perm區(qū)不斷增長(zhǎng)。 此區(qū)域大小由-XX:MaxPermSize參數(shù)進(jìn)行設(shè)置.

　　案例： Groovy動(dòng)態(tài)編譯class, xstream String.intern

　　本質(zhì)原因：ClassLoader.defineClass和java.lang.String.intern在大量不適宜的場(chǎng)景被調(diào)用.

　　解決方案：

　　方案1(直接有效): 使用btrace相關(guān)工具輸出調(diào)用ClassLoader.defineClass棧信息, 從棧信息來(lái)追溯問(wèn)題.

　　用JProfiler來(lái)trace String.intern方法棧

　　方案2: dump heap, 看看哪些class有異?，F(xiàn)象(數(shù)量), String被Perm區(qū)引用的對(duì)象信息等.但這種方式不太直觀，可以從String數(shù)據(jù)看看發(fā)現(xiàn)可疑問(wèn)題，沒有方案1直觀。(如下圖: 如果能在日常調(diào)試推薦JProfiler)

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

　　方案4：執(zhí)行jmap -permgen(jstat -gcutil 可以查看內(nèi)存增長(zhǎng)速度和區(qū)域)命令看看Perm區(qū)中的內(nèi)容, 初步確定是否存在問(wèn)題 。

　　java內(nèi)存泄露場(chǎng)景---Java heap space

　　原因：長(zhǎng)生命周期的對(duì)象引用了短生命周期(應(yīng)該盡快GC回收掉)的對(duì)象，最后造成一個(gè)對(duì)象已經(jīng)不能在堆區(qū)分配足夠空間. 注: 這種現(xiàn)象不能完全肯定是內(nèi)存泄露, 比如: heap本身的設(shè)置的過(guò)小.

　　案例： 我個(gè)人沒有遇到過(guò)這種案例, 但模擬過(guò)這種情形的Demo: 參考我的《深入淺出JProfiler》文章, 也學(xué)習(xí)過(guò)其他同學(xué)的案例: 例如:參數(shù)過(guò)大并且頻繁超時(shí)導(dǎo)致內(nèi)存泄露

　　解決方案：

　　觸發(fā)FullGC, dump live heap. 標(biāo)記堆中對(duì)象數(shù)量, 重點(diǎn)關(guān)注可疑對(duì)象

　　觸發(fā)FullGC, dump live heap. 標(biāo)記堆中對(duì)象數(shù)量, 重點(diǎn)關(guān)注可疑對(duì)象

　　對(duì)比步驟1和步驟2 相同對(duì)象的數(shù)量和大小, 找出可疑對(duì)象一一進(jìn)行排查確認(rèn)。

　　如果步驟3依然無(wú)法明確有問(wèn)題的對(duì)象, 那就多執(zhí)行幾次步驟1和步驟2。在此過(guò)程中可以調(diào)整GC觸發(fā)時(shí)間, 模擬真實(shí)的故障場(chǎng)景

　　看看GC后堆的大小是否增長(zhǎng), 如果沒有不斷增長(zhǎng), 并且持續(xù)一段較長(zhǎng)時(shí)間, 那基本正常(具體看看。

　　java內(nèi)存泄露怎么辦

　　縮小問(wèn)題的范圍

　　要找出內(nèi)存泄漏的原因當(dāng)下已經(jīng)有許多工具可用，比如JVisualVM或者jStat。這些工具是JDK自帶的，所以大家隨時(shí)都能用。除了要識(shí)別一些常用的內(nèi)部Java類，一些用戶自定義累同樣需要識(shí)別。

　　性能優(yōu)化

　　在日常的開發(fā)過(guò)程中，只要GC沒有影響到性能，開發(fā)者就不會(huì)去關(guān)注內(nèi)存設(shè)置于配置。從而埋下了潛在的隱患：因?yàn)閮?nèi)存問(wèn)題并不只有溢出和泄露，GC時(shí)間過(guò)長(zhǎng)同樣會(huì)造成這個(gè)問(wèn)題。比如下圖中GC占用了16%的CPU。

　　Heap設(shè)置

　　Heap太小會(huì)導(dǎo)致頻繁的GC，從而情景不難想象：增加GC會(huì)消耗更多的CPU，同時(shí)在GC時(shí)JVM會(huì)被凍結(jié)，最后導(dǎo)致一個(gè)很差的性能。總的來(lái)說(shuō)，Heap太小的話，雖然GC時(shí)間變短，但是會(huì)變得更加頻繁。

　　Heap太大會(huì)導(dǎo)致GC時(shí)間邊長(zhǎng)。GC不會(huì)經(jīng)常發(fā)生，但是一旦被觸發(fā)，那么VM會(huì)被凍結(jié)很久。

　　因此，如果這種情況下發(fā)生內(nèi)存泄露，在最終JVM因?yàn)閮?nèi)存溢出崩潰之前，GC會(huì)非常頻繁或者時(shí)間特別長(zhǎng)。

　　GC版本

　　從Java 6開始，GC就改變了很多。Java 7引入了G1GC作為CMS GC的替代選擇，而在Java 9中G1GC已成為默認(rèn)選擇。Java 8中移除了PermGen Space，之前存儲(chǔ)在PermGen Space中的數(shù)據(jù)則改為存儲(chǔ)在本地內(nèi)存或者棧中。

java內(nèi)存泄露的原因相關(guān)文章：

1.造成內(nèi)存泄露的原因

2.c內(nèi)存泄露的原因

3.javaweb常見面試題及參考答案