內(nèi)存泄漏是指程序在申請(qǐng)內(nèi)存后,無法釋放已申請(qǐng)的內(nèi)存空間。內(nèi)存溢出是指程序申請(qǐng)內(nèi)存時(shí),沒有足夠的內(nèi)存供申請(qǐng)者使用;或者說提供一塊存儲(chǔ)int數(shù)據(jù)的存儲(chǔ)空間,但存儲(chǔ)了long數(shù)據(jù),則結(jié)果是內(nèi)存不夠用,報(bào)錯(cuò)OOM。內(nèi)存泄漏的堆積最終會(huì)導(dǎo)致內(nèi)存溢出。
本教程操作環(huán)境:windows7系統(tǒng)、java8版、DELL G3電腦。
1、內(nèi)存泄漏memory leak :
是指程序在申請(qǐng)內(nèi)存后,無法釋放已申請(qǐng)的內(nèi)存空間,一次內(nèi)存泄漏似乎不會(huì)有大的影響,但內(nèi)存泄漏堆積后的后果就是內(nèi)存溢出。
2、內(nèi)存溢出 out of memory :
指程序申請(qǐng)內(nèi)存時(shí),沒有足夠的內(nèi)存供申請(qǐng)者使用,或者說,給了你一塊存儲(chǔ)int類型數(shù)據(jù)的存儲(chǔ)空間,但是你卻存儲(chǔ)long類型的數(shù)據(jù),那么結(jié)果就是內(nèi)存不夠用,此時(shí)就會(huì)報(bào)錯(cuò)OOM,即所謂的內(nèi)存溢出。
3、二者的關(guān)系:
-
內(nèi)存泄漏的堆積最終會(huì)導(dǎo)致內(nèi)存溢出
-
內(nèi)存溢出就是你要的內(nèi)存空間超過了系統(tǒng)實(shí)際分配給你的空間,此時(shí)系統(tǒng)相當(dāng)于沒法滿足你的需求,就會(huì)報(bào)內(nèi)存溢出的錯(cuò)誤。
-
內(nèi)存泄漏是指你向系統(tǒng)申請(qǐng)分配內(nèi)存進(jìn)行使用(new),可是使用完了以后卻不歸還(delete),結(jié)果你申請(qǐng)到的那塊內(nèi)存你自己也不能再訪問(也許你把它的地址給弄丟了),而系統(tǒng)也不能再次將它分配給需要的程序。就相當(dāng)于你租了個(gè)帶鑰匙的柜子,你存完東西之后把柜子鎖上之后,把鑰匙丟了或者沒有將鑰匙還回去,那么結(jié)果就是這個(gè)柜子將無法供給任何人使用,也無法被垃圾回收器回收,因?yàn)檎也坏剿娜魏涡畔ⅰ?/p>
-
內(nèi)存溢出:一個(gè)盤子用盡各種方法只能裝4個(gè)果子,你裝了5個(gè),結(jié)果掉倒地上不能吃了。這就是溢出。比方說棧,棧滿時(shí)再做進(jìn)棧必定產(chǎn)生空間溢出,叫上溢,??諘r(shí)再做退棧也產(chǎn)生空間溢出,稱為下溢。就是分配的內(nèi)存不足以放下數(shù)據(jù)項(xiàng)序列,稱為內(nèi)存溢出。說白了就是我承受不了那么多,那我就報(bào)錯(cuò)。
4、內(nèi)存泄漏的分類(按發(fā)生方式來分類)
-
常發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼會(huì)被多次執(zhí)行到,每次被執(zhí)行的時(shí)候都會(huì)導(dǎo)致一塊內(nèi)存泄漏。
-
偶發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只有在某些特定環(huán)境或操作過程下才會(huì)發(fā)生。常發(fā)性和偶發(fā)性是相對(duì)的。對(duì)于特定的環(huán)境,偶發(fā)性的也許就變成了常發(fā)性的。所以測試環(huán)境和測試方法對(duì)檢測內(nèi)存泄漏至關(guān)重要。
-
一次性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只會(huì)被執(zhí)行一次,或者由于算法上的缺陷,導(dǎo)致總會(huì)有一塊僅且一塊內(nèi)存發(fā)生泄漏。比如,在類的構(gòu)造函數(shù)中分配內(nèi)存,在析構(gòu)函數(shù)中卻沒有釋放該內(nèi)存,所以內(nèi)存泄漏只會(huì)發(fā)生一次。
-
隱式內(nèi)存泄漏。程序在運(yùn)行過程中不停的分配內(nèi)存,但是直到結(jié)束的時(shí)候才釋放內(nèi)存。嚴(yán)格的說這里并沒有發(fā)生內(nèi)存泄漏,因?yàn)樽罱K程序釋放了所有申請(qǐng)的內(nèi)存。但是對(duì)于一個(gè)服務(wù)器程序,需要運(yùn)行幾天,幾周甚至幾個(gè)月,不及時(shí)釋放內(nèi)存也可能導(dǎo)致最終耗盡系統(tǒng)的所有內(nèi)存。所以,我們稱這類內(nèi)存泄漏為隱式內(nèi)存泄漏。
5、內(nèi)存溢出的原因及解決方法:
(1) 內(nèi)存溢出原因:
-
內(nèi)存中加載的數(shù)據(jù)量過于龐大,如一次從數(shù)據(jù)庫取出過多數(shù)據(jù);
-
集合類中有對(duì)對(duì)象的引用,使用完后未清空,使得JVM不能回收;
-
代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復(fù)的對(duì)象實(shí)體;
-
使用的第三方軟件中的BUG;
-
啟動(dòng)參數(shù)內(nèi)存值設(shè)定的過小
(2)內(nèi)存溢出的解決方案:
第一步,修改JVM啟動(dòng)參數(shù),直接增加內(nèi)存。(-Xms,-Xmx參數(shù)一定不要忘記加。)
第二步,檢查錯(cuò)誤日志,查看“OutOfMemory”錯(cuò)誤前是否有其 它異?;蝈e(cuò)誤。
第三步,對(duì)代碼進(jìn)行走查和分析,找出可能發(fā)生內(nèi)存溢出的位置。
重點(diǎn)排查以下幾點(diǎn):
-
檢查對(duì)數(shù)據(jù)庫查詢中,是否有一次獲得全部數(shù)據(jù)的查詢。一般來說,如果一次取十萬條記錄到內(nèi)存,就可能引起內(nèi)存溢出。這個(gè)問題比較隱蔽,在上線前,數(shù)據(jù)庫中數(shù)據(jù)較少,不容易出問題,上線后,數(shù)據(jù)庫中數(shù)據(jù)多了,一次查詢就有可能引起內(nèi)存溢出。因此對(duì)于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
-
檢查代碼中是否有死循環(huán)或遞歸調(diào)用。
-
檢查是否有大循環(huán)重復(fù)產(chǎn)生新對(duì)象實(shí)體。
-
檢查對(duì)數(shù)據(jù)庫查詢中,是否有一次獲得全部數(shù)據(jù)的查詢。一般來說,如果一次取十萬條記錄到內(nèi)存,就可能引起內(nèi)存溢出。這個(gè)問題比較隱蔽,在上線前,數(shù)據(jù)庫中數(shù)據(jù)較少,不容易出問題,上線后,數(shù)據(jù)庫中數(shù)據(jù)多了,一次查詢就有可能引起內(nèi)存溢出。因此對(duì)于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
-
檢查List、MAP等集合對(duì)象是否有使用完后,未清除的問題。List、MAP等集合對(duì)象會(huì)始終存有對(duì)對(duì)象的引用,使得這些對(duì)象不能被GC回收。
第四步,使用內(nèi)存查看工具動(dòng)態(tài)查看內(nèi)存使用情況
JVM8 內(nèi)存模型
內(nèi)存溢出的十個(gè)場景
JVM運(yùn)行時(shí)首先需要類加載器(classLoader)加載所需類的字節(jié)碼文件。加載完畢交由執(zhí)行引擎執(zhí)行,在執(zhí)行過程中需要一段空間來存儲(chǔ)數(shù)據(jù)(類比CPU與主存)。這段內(nèi)存空間的分配和釋放過程正是我們需要關(guān)心的運(yùn)行時(shí)數(shù)據(jù)區(qū)。內(nèi)存溢出的情況就是從類加載器加載的時(shí)候開始出現(xiàn)的,內(nèi)存溢出分為兩大類:OutOfMemoryError和StackOverflowError。以下舉出10個(gè)內(nèi)存溢出的情況,并通過實(shí)例代碼的方式講解了是如何出現(xiàn)內(nèi)存溢出的。
1.java堆內(nèi)存溢出
當(dāng)出現(xiàn)java.lang.OutOfMemoryError:Java heap space異常時(shí),就是堆內(nèi)存溢出了。
1)、問題描述
-
設(shè)置的jvm內(nèi)存太小,對(duì)象所需內(nèi)存太大,創(chuàng)建對(duì)象時(shí)分配空間,就會(huì)拋出這個(gè)異常。
-
流量/數(shù)據(jù)峰值,應(yīng)用程序自身的處理存在一定的限額,比如一定數(shù)量的用戶或一定數(shù)量的數(shù)據(jù)。而當(dāng)用戶數(shù)量或數(shù)據(jù)量突然激增并超過預(yù)期的閾值時(shí),那么就會(huì)峰值停止前正常運(yùn)行的操作將停止并觸發(fā)java . lang.OutOfMemoryError:Java堆空間錯(cuò)誤
2)、示例代碼
編譯以下代碼,執(zhí)行時(shí)jvm參數(shù)設(shè)置為-Xms20m -Xmx20m
以上這個(gè)示例,如果一次請(qǐng)求只分配一次5m的內(nèi)存的話,請(qǐng)求量很少垃圾回收正常就不會(huì)出錯(cuò),但是一旦并發(fā)上來就會(huì)超出最大內(nèi)存值,就會(huì)拋出內(nèi)存溢出。
3.解決方法
首先,如果代碼沒有什么問題的情況下,可以適當(dāng)調(diào)整-Xms和-Xmx兩個(gè)jvm參數(shù),使用壓力測試來調(diào)整這兩個(gè)參數(shù)達(dá)到最優(yōu)值。
其次,盡量避免大的對(duì)象的申請(qǐng),像文件上傳,大批量從數(shù)據(jù)庫中獲取,這是需要避免的,盡量分塊或者分批處理,有助于系統(tǒng)的正常穩(wěn)定的執(zhí)行。
最后,盡量提高一次請(qǐng)求的執(zhí)行速度,垃圾回收越早越好,否則,大量的并發(fā)來了的時(shí)候,再來新的請(qǐng)求就無法分配內(nèi)存了,就容易造成系統(tǒng)的雪崩。
2、java堆內(nèi)存泄漏
1)、問題描述
Java中的內(nèi)存泄漏是一些對(duì)象不再被應(yīng)用程序使用但垃圾收集無法識(shí)別的情況。因此,這些未使用的對(duì)象仍然在Java堆空間中無限期地存在。不停的堆積最終會(huì)觸發(fā)java . lang.OutOfMemoryError。
2)、示例代碼
當(dāng)執(zhí)行上面的代碼時(shí),可能會(huì)期望它永遠(yuǎn)運(yùn)行,不會(huì)出現(xiàn)任何問題,假設(shè)單純的緩存解決方案只將底層映射擴(kuò)展到10,000個(gè)元素,而不是所有鍵都已經(jīng)在HashMap中。然而事實(shí)上元素將繼續(xù)被添加,因?yàn)閗ey類并沒有重寫它的equals()方法。
隨著時(shí)間的推移,隨著不斷使用的泄漏代碼,“緩存”的結(jié)果最終會(huì)消耗大量Java堆空間。當(dāng)泄漏內(nèi)存填充堆區(qū)域中的所有可用內(nèi)存時(shí),垃圾收集無法清理它,java . lang.OutOfMemoryError。
3)、解決辦法
相對(duì)來說對(duì)應(yīng)的解決方案比較簡單:重寫equals方法即可:
3.垃圾回收超時(shí)內(nèi)存溢出
1)、問題描述 當(dāng)應(yīng)用程序耗盡所有可用內(nèi)存時(shí),GC開銷限制超過了錯(cuò)誤,而GC多次未能清除它,這時(shí)便會(huì)引發(fā)java.lang.OutOfMemoryError。當(dāng)JVM花費(fèi)大量的時(shí)間執(zhí)行GC,而收效甚微,而一旦整個(gè)GC的過程超過限制便會(huì)觸發(fā)錯(cuò)誤(默認(rèn)的jvm配置GC的時(shí)間超過98%,回收堆內(nèi)存低于2%)。
2)、示例代碼
3)、解決方法
要減少對(duì)象生命周期,盡量能快速的進(jìn)行垃圾回收。
4.Metaspace內(nèi)存溢出
1)、問題描述
元空間的溢出,系統(tǒng)會(huì)拋出java.lang.OutOfMemoryError: Metaspace。出現(xiàn)這個(gè)異常的問題的原因是系統(tǒng)的代碼非常多或引用的第三方包非常多或者通過動(dòng)態(tài)代碼生成類加載等方法,導(dǎo)致元空間的內(nèi)存占用很大。
2)、示例代碼
3)、解決辦法
默認(rèn)情況下,元空間的大小僅受本地內(nèi)存限制。但是為了整機(jī)的性能,盡量還是要對(duì)該項(xiàng)進(jìn)行設(shè)置,以免造成整機(jī)的服務(wù)停機(jī)。
-
優(yōu)化參數(shù)配置,避免影響其他JVM進(jìn)程
-XX:MetaspaceSize,初始空間大小,達(dá)到該值就會(huì)觸發(fā)垃圾收集進(jìn)行類型卸載,同時(shí)GC會(huì)對(duì)該值進(jìn)行調(diào)整:如果釋放了大量的空間,就適當(dāng)降低該值;如果釋放了很少的空間,那么在不超過MaxMetaspaceSize時(shí),適當(dāng)提高該值。
-XX:MaxMetaspaceSize,最大空間,默認(rèn)是沒有限制的。
除了上面兩個(gè)指定大小的選項(xiàng)以外,還有兩個(gè)與 GC 相關(guān)的屬性: -XX:MinMetaspaceFreeRatio,在GC之后,最小的Metaspace剩余空間容量的百分比,減少為分配空間所導(dǎo)致的垃圾收集 。 -XX:MaxMetaspaceFreeRatio,在GC之后,最大的Metaspace剩余空間容量的百分比,減少為釋放空間所導(dǎo)致的垃圾收集。
-
慎重引用第三方包
對(duì)第三方包,一定要慎重選擇,不需要的包就去掉。這樣既有助于提高編譯打包的速度,也有助于提高遠(yuǎn)程部署的速度。
-
關(guān)注動(dòng)態(tài)生成類的框架
對(duì)于使用大量動(dòng)態(tài)生成類的框架,要做好壓力測試,驗(yàn)證動(dòng)態(tài)生成的類是否超出內(nèi)存的需求會(huì)拋出異常。
5、直接內(nèi)存內(nèi)存溢出
1)、問題描述
在使用ByteBuffer中的allocateDirect()的時(shí)候會(huì)用到,很多javaNIO(像netty)的框架中被封裝為其他的方法,出現(xiàn)該問題時(shí)會(huì)拋出java.lang.OutOfMemoryError: Direct buffer memory異常。
如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時(shí)候,而不做clear的時(shí)候就會(huì)出現(xiàn)類似的問題。
2)、示例代碼
3)、解決辦法
如果經(jīng)常有類似的操作,可以考慮設(shè)置參數(shù):-XX:MaxDirectMemorySize,并及時(shí)clear內(nèi)存。
6、棧內(nèi)存溢出
1)、問題描述
當(dāng)一個(gè)線程執(zhí)行一個(gè)Java方法時(shí),JVM將創(chuàng)建一個(gè)新的棧幀并且把它push到棧頂。此時(shí)新的棧幀就變成了當(dāng)前棧幀,方法執(zhí)行時(shí),使用棧幀來存儲(chǔ)參數(shù)、局部變量、中間指令以及其他數(shù)據(jù)。
當(dāng)一個(gè)方法遞歸調(diào)用自己時(shí),新的方法所產(chǎn)生的數(shù)據(jù)(也可以理解為新的棧幀)將會(huì)被push到棧頂,方法每次調(diào)用自己時(shí),會(huì)拷貝一份當(dāng)前方法的數(shù)據(jù)并push到棧中。因此,遞歸的每層調(diào)用都需要?jiǎng)?chuàng)建一個(gè)新的棧幀。這樣的結(jié)果是,棧中越來越多的內(nèi)存將隨著遞歸調(diào)用而被消耗,如果遞歸調(diào)用自己一百萬次,那么將會(huì)產(chǎn)生一百萬個(gè)棧幀。這樣就會(huì)造成棧的內(nèi)存溢出。
2)、示例代碼
3)、解決辦法
如果程序中確實(shí)有遞歸調(diào)用,出現(xiàn)棧溢出時(shí),可以調(diào)高-Xss大小,就可以解決棧內(nèi)存溢出的問題了。遞歸調(diào)用防止形成死循環(huán),否則就會(huì)出現(xiàn)棧內(nèi)存溢出。
7、創(chuàng)建本地線程內(nèi)存溢出
1)、問題描述
線程基本只占用heap以外的內(nèi)存區(qū)域,也就是這個(gè)錯(cuò)誤說明除了heap以外的區(qū)域,無法為線程分配一塊內(nèi)存區(qū)域了,這個(gè)要么是內(nèi)存本身就不夠,要么heap的空間設(shè)置得太大了,導(dǎo)致了剩余的內(nèi)存已經(jīng)不多了,而由于線程本身要占用內(nèi)存,所以就不夠用了。
2)、示例代碼
3)、解決方法
首先檢查操作系統(tǒng)是否有線程數(shù)的限制,使用shell也無法創(chuàng)建線程,如果是這個(gè)問題就需要調(diào)整系統(tǒng)的最大可支持的文件數(shù)。
日常開發(fā)中盡量保證線程最大數(shù)的可控制的,不要隨意使用線程池。不能無限制的增長下去。
8、超出交換區(qū)內(nèi)存溢出
1)、問題描述
在Java應(yīng)用程序啟動(dòng)過程中,可以通過-Xmx和其他類似的啟動(dòng)參數(shù)限制指定的所需的內(nèi)存。而當(dāng)JVM所請(qǐng)求的總內(nèi)存大于可用物理內(nèi)存的情況下,操作系統(tǒng)開始將內(nèi)容從內(nèi)存轉(zhuǎn)換為硬盤。
一般來說JVM會(huì)拋出Out of swap space錯(cuò)誤,代表應(yīng)用程序向JVM native heap請(qǐng)求分配內(nèi)存失敗并且native heap也即將耗盡時(shí),錯(cuò)誤消息中包含分配失敗的大?。ㄒ宰止?jié)為單位)和請(qǐng)求失敗的原因。
2)、解決辦法
增加系統(tǒng)交換區(qū)的大小,我個(gè)人認(rèn)為,如果使用了交換區(qū),性能會(huì)大大降低,不建議采用這種方式,生產(chǎn)環(huán)境盡量避免最大內(nèi)存超過系統(tǒng)的物理內(nèi)存。其次,去掉系統(tǒng)交換區(qū),只使用系統(tǒng)的內(nèi)存,保證應(yīng)用的性能。
9、數(shù)組超限內(nèi)存溢出
1)、問題描述 有的時(shí)候會(huì)碰到這種內(nèi)存溢出的描述Requested array size exceeds VM limit,一般來說java對(duì)應(yīng)用程序所能分配數(shù)組最大大小是有限制的,只不過不同的平臺(tái)限制有所不同,但通常在1到21億個(gè)元素之間。當(dāng)Requested array size exceeds VM limit錯(cuò)誤出現(xiàn)時(shí),意味著應(yīng)用程序試圖分配大于Java虛擬機(jī)可以支持的數(shù)組。JVM在為數(shù)組分配內(nèi)存之前,會(huì)執(zhí)行特定平臺(tái)的檢查:分配的數(shù)據(jù)結(jié)構(gòu)是否在此平臺(tái)是可尋址的。
2)、示例代碼
以下就是代碼就是數(shù)組超出了最大限制。
3)、解決方法
因此數(shù)組長度要在平臺(tái)允許的長度范圍之內(nèi)。不過這個(gè)錯(cuò)誤一般少見的,主要是由于Java數(shù)組的索引是int類型。 Java中的最大正整數(shù)為2 ^ 31 – 1 = 2,147,483,647。 并且平臺(tái)特定的限制可以非常接近這個(gè)數(shù)字,例如:我的環(huán)境上(64位macOS,運(yùn)行Jdk1.8)可以初始化數(shù)組的長度高達(dá)2,147,483,645(Integer.MAX_VALUE-2)。若是在將數(shù)組的長度再增加1達(dá)到nteger.MAX_VALUE-1會(huì)出現(xiàn)的OutOfMemoryError。
10、系統(tǒng)殺死進(jìn)程內(nèi)存溢出
1)、問題概述 在描述該問題之前,先熟悉一點(diǎn)操作系統(tǒng)的知識(shí):操作系統(tǒng)是建立在進(jìn)程的概念之上,這些進(jìn)程在內(nèi)核中作業(yè),其中有一個(gè)非常特殊的進(jìn)程,稱為“內(nèi)存殺手(Out of memory killer)”。當(dāng)內(nèi)核檢測到系統(tǒng)內(nèi)存不足時(shí),OOM killer被激活,檢查當(dāng)前誰占用內(nèi)存最多然后將該進(jìn)程殺掉。
一般Out of memory:Kill process or sacrifice child錯(cuò)會(huì)在當(dāng)可用虛擬虛擬內(nèi)存(包括交換空間)消耗到讓整個(gè)操作系統(tǒng)面臨風(fēng)險(xiǎn)時(shí),會(huì)被觸發(fā)。在這種情況下,OOM Killer會(huì)選擇“流氓進(jìn)程”并殺死它。
2)、示例代碼
3)、解決方法
雖然增加交換空間的方式可以緩解Java heap space異常,還是建議最好的方案就是升級(jí)系統(tǒng)內(nèi)存,讓java應(yīng)用有足夠的內(nèi)存可用,就不會(huì)出現(xiàn)這種問題。
總結(jié) 通過以上的10種出現(xiàn)內(nèi)存溢出情況,大家在實(shí)際碰到問題時(shí)也就會(huì)知道怎么解決了,在實(shí)際編碼中也要記得:
-
第三方j(luò)ar包要慎重引入,堅(jiān)決去掉沒有用的jar包,提高編譯的速度和系統(tǒng)的占用內(nèi)存。
-
對(duì)于大的對(duì)象或者大量的內(nèi)存申請(qǐng),要進(jìn)行優(yōu)化,大的對(duì)象要分片處理,提高處理性能,減少對(duì)象生命周期。
-
盡量固定線程的數(shù)量,保證線程占用內(nèi)存可控,同時(shí)需要大量線程時(shí),要優(yōu)化好操作系統(tǒng)的最大可打開的連接數(shù)。
-
對(duì)于遞歸調(diào)用,也要控制好遞歸的層級(jí),不要太高,超過棧的深度。
-
分配給棧的內(nèi)存并不是越大越好,因?yàn)闂?nèi)存越大,線程多,留給堆的空間就不多了,容易拋出OOM。JVM的默認(rèn)參數(shù)一般情況沒有問題(包括遞歸)。
相關(guān)視頻教程推薦:Java視頻教程