內存溢出

JVM運行時首先需要類加載器（classLoader）加載所需類的字節(jié)碼文件。加載完畢交由執(zhí)行引擎執(zhí)行，在執(zhí)行過程中需要一段空間來存儲數(shù)據(jù)（類比CPU與主存）。這段內存空間的分配和釋放過程正是我們需要關心的運行時數(shù)據(jù)區(qū)。內存溢出的情況就是從類加載器加載的時候開始出現(xiàn)的，內存溢出分為兩大類：OutOfMemoryError和StackOverflowError。以下舉出10個內存溢出的情況，并通過實例代碼的方式講解了是如何出現(xiàn)內存溢出的。

java堆內存溢出

當出現(xiàn)java.lang.OutOfMemoryError:Java heap space異常時，就是堆內存溢出了。
問題描述
設置的jvm內存太小，對象所需內存太大，創(chuàng)建對象時分配空間，就會拋出這個異常。
流量/數(shù)據(jù)峰值，應用程序自身的處理存在一定的限額，比如一定數(shù)量的用戶或一定數(shù)量的數(shù)據(jù)。而當用戶數(shù)量或數(shù)據(jù)量突然激增并超過預期的閾值時，那么就會峰值停止前正常運行的操作將停止并觸發(fā)java . lang.OutOfMemoryError:Java堆空間錯誤
解決方法
首先，如果代碼沒有什么問題的情況下，可以適當調整-Xms和-Xmx兩個jvm參數(shù)，使用壓力測試來調整這兩個參數(shù)達到最優(yōu)值。
其次，盡量避免大的對象的申請，像文件上傳，大批量從數(shù)據(jù)庫中獲取，這是需要避免的，盡量分塊或者分批處理，有助于系統(tǒng)的正常穩(wěn)定的執(zhí)行。
最后，盡量提高一次請求的執(zhí)行速度，垃圾回收越早越好，否則，大量的并發(fā)來了的時候，再來新的請求就無法分配內存了，就容易造成系統(tǒng)的雪崩。

java堆內存泄漏

問題描述
Java中的內存泄漏是一些對象不再被應用程序使用但垃圾收集無法識別的情況。因此，這些未使用的對象仍然在Java堆空間中無限期地存在。不停的堆積最終會觸發(fā)java . lang.OutOfMemoryError。

垃圾回收超時內存溢出

問題描述
當應用程序耗盡所有可用內存時，GC開銷限制超過了錯誤，而GC多次未能清除它，這時便會引發(fā)java.lang.OutOfMemoryError。當JVM花費大量的時間執(zhí)行GC，而收效甚微，而一旦整個GC的過程超過限制便會觸發(fā)錯誤(默認的jvm配置GC的時間超過98%，回收堆內存低于2%)
解決方法
要減少對象生命周期，盡量能快速的進行垃圾回收。

Metaspace內存溢出

問題描述
元空間的溢出，系統(tǒng)會拋出java.lang.OutOfMemoryError: Metaspace。出現(xiàn)這個異常的問題的原因是系統(tǒng)的代碼非常多或引用的第三方包非常多或者通過動態(tài)代碼生成類加載等方法，導致元空間的內存占用很大。
.解決辦法
默認情況下，元空間的大小僅受本地內存限制。但是為了整機的性能，盡量還是要對該項進行設置，以免造成整機的服務停機。
1）優(yōu)化參數(shù)配置，避免影響其他JVM進程
-XX:MetaspaceSize，初始空間大小，達到該值就會觸發(fā)垃圾收集進行類型卸載，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過MaxMetaspaceSize時，適當提高該值。
-XX:MaxMetaspaceSize，最大空間，默認是沒有限制的。
除了上面兩個指定大小的選項以外，還有兩個與 GC 相關的屬性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空間容量的百分比，減少為分配空間所導致的垃圾收集 。
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空間容量的百分比，減少為釋放空間所導致的垃圾收集。
2）慎重引用第三方包
對第三方包，一定要慎重選擇，不需要的包就去掉。這樣既有助于提高編譯打包的速度，也有助于提高遠程部署的速度。
3）關注動態(tài)生成類的框架
對于使用大量動態(tài)生成類的框架，要做好壓力測試，驗證動態(tài)生成的類是否超出內存的需求會拋出異常。

直接內存內存溢出

問題描述
在使用ByteBuffer中的allocateDirect()的時候會用到，很多javaNIO(像netty)的框架中被封裝為其他的方法，出現(xiàn)該問題時會拋出java.lang.OutOfMemoryError: Direct buffer memory異常。
如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時候，而不做clear的時候就會出現(xiàn)類似的問題。

棧內存溢出

問題描述
當一個線程執(zhí)行一個Java方法時，JVM將創(chuàng)建一個新的棧幀并且把它push到棧頂。此時新的棧幀就變成了當前棧幀，方法執(zhí)行時，使用棧幀來存儲參數(shù)、局部變量、中間指令以及其他數(shù)據(jù)。
當一個方法遞歸調用自己時，新的方法所產(chǎn)生的數(shù)據(jù)(也可以理解為新的棧幀)將會被push到棧頂，方法每次調用自己時，會拷貝一份當前方法的數(shù)據(jù)并push到棧中。因此，遞歸的每層調用都需要創(chuàng)建一個新的棧幀。這樣的結果是，棧中越來越多的內存將隨著遞歸調用而被消耗，如果遞歸調用自己一百萬次，那么將會產(chǎn)生一百萬個棧幀。這樣就會造成棧的內存溢出。
解決辦法
如果程序中確實有遞歸調用，出現(xiàn)棧溢出時，可以調高-Xss大小，就可以解決棧內存溢出的問題了。遞歸調用防止形成死循環(huán)，否則就會出現(xiàn)棧內存溢出。

創(chuàng)建本地線程內存溢出

問題描述
線程基本只占用heap以外的內存區(qū)域，也就是這個錯誤說明除了heap以外的區(qū)域，無法為線程分配一塊內存區(qū)域了，這個要么是內存本身就不夠，要么heap的空間設置得太大了，導致了剩余的內存已經(jīng)不多了，而由于線程本身要占用內存，所以就不夠用了。
解決方法
首先檢查操作系統(tǒng)是否有線程數(shù)的限制，使用shell也無法創(chuàng)建線程，如果是這個問題就需要調整系統(tǒng)的最大可支持的文件數(shù)。
日常開發(fā)中盡量保證線程最大數(shù)的可控制的，不要隨意使用線程池。不能無限制的增長下去。

超出交換區(qū)內存溢出

問題描述
在Java應用程序啟動過程中，可以通過-Xmx和其他類似的啟動參數(shù)限制指定的所需的內存。而當JVM所請求的總內存大于可用物理內存的情況下，操作系統(tǒng)開始將內容從內存轉換為硬盤。
一般來說JVM會拋出Out of swap space錯誤，代表應用程序向JVM native heap請求分配內存失敗并且native heap也即將耗盡時，錯誤消息中包含分配失敗的大小（以字節(jié)為單位）和請求失敗的原因。
解決辦法
增加系統(tǒng)交換區(qū)的大小，我個人認為，如果使用了交換區(qū)，性能會大大降低，不建議采用這種方式，生產(chǎn)環(huán)境盡量避免最大內存超過系統(tǒng)的物理內存。其次，去掉系統(tǒng)交換區(qū)，只使用系統(tǒng)的內存，保證應用的性能。

數(shù)組超限內存溢出

問題描述
有的時候會碰到這種內存溢出的描述Requested array size exceeds VM limit，一般來說java對應用程序所能分配數(shù)組最大大小是有限制的，只不過不同的平臺限制有所不同，但通常在1到21億個元素之間。當Requested array size exceeds VM limit錯誤出現(xiàn)時，意味著應用程序試圖分配大于Java虛擬機可以支持的數(shù)組。JVM在為數(shù)組分配內存之前，會執(zhí)行特定平臺的檢查：分配的數(shù)據(jù)結構是否在此平臺是可尋址的。
解決方法
因此數(shù)組長度要在平臺允許的長度范圍之內。不過這個錯誤一般少見的，主要是由于Java數(shù)組的索引是int類型。 Java中的最大正整數(shù)為2 ^ 31 - 1 = 2,147,483,647。 并且平臺特定的限制可以非常接近這個數(shù)字，例如：我的環(huán)境上(64位macOS，運行Jdk1.8)可以初始化數(shù)組的長度高達2,147,483,645（Integer.MAX_VALUE-2）。若是在將數(shù)組的長度再增加1達到nteger.MAX_VALUE-1會出現(xiàn)的OutOfMemoryError。

系統(tǒng)殺死進程內存溢出

問題概述
在描述該問題之前，先熟悉一點操作系統(tǒng)的知識：操作系統(tǒng)是建立在進程的概念之上，這些進程在內核中作業(yè)，其中有一個非常特殊的進程，稱為“內存殺手（Out of memory killer）”。當內核檢測到系統(tǒng)內存不足時，OOM killer被激活，檢查當前誰占用內存最多然后將該進程殺掉。
一般Out of memory:Kill process or sacrifice child錯會在當可用虛擬虛擬內存(包括交換空間)消耗到讓整個操作系統(tǒng)面臨風險時，會被觸發(fā)。在這種情況下，OOM Killer會選擇“流氓進程”并殺死它。
雖然增加交換空間的方式可以緩解Java heap space異常，還是建議最好的方案就是升級系統(tǒng)內存，讓java應用有足夠的內存可用，就不會出現(xiàn)這種問題。

總結

通過以上的10種出現(xiàn)內存溢出情況，大家在實際碰到問題時也就會知道怎么解決了，在實際編碼中也要記得：
1.第三方jar包要慎重引入，堅決去掉沒有用的jar包，提高編譯的速度和系統(tǒng)的占用內存。
2.對于大的對象或者大量的內存申請，要進行優(yōu)化，大的對象要分片處理，提高處理性能，減少對象生命周期。
3.盡量固定線程的數(shù)量，保證線程占用內存可控，同時需要大量線程時，要優(yōu)化好操作系統(tǒng)的最大可打開的連接數(shù)。
4.對于遞歸調用，也要控制好遞歸的層級，不要太高，超過棧的深度。
5.分配給棧的內存并不是越大越好，因為棧內存越大，線程多，留給堆的空間就不多了，容易拋出OOM。JVM的默認參數(shù)一般情況沒有問題（包括遞歸）。

到此這篇關于淺談JVM內存溢出的幾種方式與解決方法的文章就介紹到這了,更多相關JVM內存溢出內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論