java中記憶體漏失和記憶體溢位是什麼

2021-09-22 19:00:22

記憶體漏失是指程式在申請記憶體後,無法釋放已申請的記憶體空間。記憶體溢位是指程式申請記憶體時,沒有足夠的記憶體供申請者使用;或者說提供一塊儲存int資料的儲存空間,但儲存了long資料,則結果是記憶體不夠用,報錯OOM。記憶體漏失的堆積最終會導致記憶體溢位。

本教學操作環境:windows7系統、java8版、DELL G3電腦。

1、記憶體漏失memory leak :

是指程式在申請記憶體後,無法釋放已申請的記憶體空間,一次記憶體漏失似乎不會有大的影響,但記憶體漏失堆積後的後果就是記憶體溢位。

2、記憶體溢位 out of memory :

指程式申請記憶體時,沒有足夠的記憶體供申請者使用,或者說,給了你一塊儲存int型別資料的儲存空間,但是你卻儲存long型別的資料,那麼結果就是記憶體不夠用,此時就會報錯OOM,即所謂的記憶體溢位。

3、二者的關係:

  • 記憶體漏失的堆積最終會導致記憶體溢位

  • 記憶體溢位就是你要的記憶體空間超過了系統實際分配給你的空間,此時系統相當於沒法滿足你的需求,就會報記憶體溢位的錯誤。

  • 記憶體漏失是指你向系統申請分配記憶體進行使用(new),可是使用完了以後卻不歸還(delete),結果你申請到的那塊記憶體你自己也不能再存取(也許你把它的地址給弄丟了),而系統也不能再次將它分配給需要的程式。就相當於你租了個帶鑰匙的櫃子,你存完東西之後把櫃子鎖上之後,把鑰匙丟了或者沒有將鑰匙還回去,那麼結果就是這個櫃子將無法供給任何人使用,也無法被垃圾回收器回收,因為找不到他的任何資訊。

  • 記憶體溢位:一個盤子用盡各種方法只能裝4個果子,你裝了5個,結果掉倒地上不能吃了。這就是溢位。比方說棧,棧滿時再做進棧必定產生空間溢位,叫上溢,棧空時再做退棧也產生空間溢位,稱為下溢。就是分配的記憶體不足以放下資料項序列,稱為記憶體溢位。說白了就是我承受不了那麼多,那我就報錯。

4、記憶體漏失的分類(按發生方式來分類)

  • 常發性記憶體漏失。發生記憶體漏失的程式碼會被多次執行到,每次被執行的時候都會導致一塊記憶體漏失。

  • 偶發性記憶體漏失。發生記憶體漏失的程式碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對於特定的環境,偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測記憶體漏失至關重要。

  • 一次性記憶體漏失。發生記憶體漏失的程式碼只會被執行一次,或者由於演演算法上的缺陷,導致總會有一塊僅且一塊記憶體發生洩漏。比如,在類別建構函式中分配記憶體,在解構函式中卻沒有釋放該記憶體,所以記憶體漏失只會發生一次。

  • 隱式記憶體漏失。程式在執行過程中不停的分配記憶體,但是直到結束的時候才釋放記憶體。嚴格的說這裡並沒有發生記憶體漏失,因為最終程式釋放了所有申請的記憶體。但是對於一個伺服器程式,需要執行幾天,幾周甚至幾個月,不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體。所以,我們稱這類記憶體漏失為隱式記憶體漏失。

5、記憶體溢位的原因及解決方法:

(1) 記憶體溢位原因:

  • 記憶體中載入的資料量過於龐大,如一次從資料庫取出過多資料;

  • 集合類中有對物件的參照,使用完後未清空,使得JVM不能回收;

  • 程式碼中存在死迴圈或迴圈產生過多重複的物件實體;

  • 使用的第三方軟體中的BUG;

  • 啟動引數記憶體值設定的過小

(2)記憶體溢位的解決方案:

第一步,修改JVM啟動引數,直接增加記憶體。(-Xms,-Xmx引數一定不要忘記加。)

第二步,檢查錯誤紀錄檔,檢視「OutOfMemory」錯誤前是否有其 它異常或錯誤。

第三步,對程式碼進行走查和分析,找出可能發生記憶體溢位的位置。

重點排查以下幾點:

  • 檢查對資料庫查詢中,是否有一次獲得全部資料的查詢。一般來說,如果一次取十萬條記錄到記憶體,就可能引起記憶體溢位。這個問題比較隱蔽,在上線前,資料庫中資料較少,不容易出問題,上線後,資料庫中資料多了,一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。

  • 檢查程式碼中是否有死迴圈或遞迴呼叫。

  • 檢查是否有大回圈重複產生新物件實體。

  • 檢查對資料庫查詢中,是否有一次獲得全部資料的查詢。一般來說,如果一次取十萬條記錄到記憶體,就可能引起記憶體溢位。這個問題比較隱蔽,在上線前,資料庫中資料較少,不容易出問題,上線後,資料庫中資料多了,一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。

  • 檢查List、MAP等集合物件是否有使用完後,未清除的問題。List、MAP等集合物件會始終存有對物件的參照,使得這些物件不能被GC回收。

第四步,使用記憶體檢視工具動態檢視記憶體使用情況

JVM8 記憶體模型

記憶體溢位的十個場景

JVM執行時首先需要類載入器(classLoader)載入所需類的位元組碼檔案。載入完畢交由執行引擎執行,在執行過程中需要一段空間來儲存資料(類比CPU與主記憶體)。這段記憶體空間的分配和釋放過程正是我們需要關心的執行時資料區。記憶體溢位的情況就是從類載入器載入的時候開始出現的,記憶體溢位分為兩大類:OutOfMemoryError和StackOverflowError。以下舉出10個記憶體溢位的情況,並通過範例程式碼的方式講解了是如何出現記憶體溢位的。

1.java堆記憶體溢位

當出現java.lang.OutOfMemoryError:Java heap space異常時,就是堆記憶體溢位了。

1)、問題描述

  • 設定的jvm記憶體太小,物件所需記憶體太大,建立物件時分配空間,就會丟擲這個異常。

  • 流量/資料峰值,應用程式自身的處理存在一定的限額,比如一定數量的使用者或一定數量的資料。而當使用者數量或資料量突然激增並超過預期的閾值時,那麼就會峰值停止前正常執行的操作將停止並觸發java . lang.OutOfMemoryError:Java堆空間錯誤

2)、範例程式碼

編譯以下程式碼,執行時jvm引數設定為-Xms20m -Xmx20m

以上這個範例,如果一次請求只分配一次5m的記憶體的話,請求量很少垃圾回收正常就不會出錯,但是一旦並行上來就會超出最大記憶體值,就會丟擲記憶體溢位。

3.解決方法

首先,如果程式碼沒有什麼問題的情況下,可以適當調整-Xms和-Xmx兩個jvm引數,使用壓力測試來調整這兩個引數達到最優值。

其次,儘量避免大的物件的申請,像檔案上傳,大批次從資料庫中獲取,這是需要避免的,儘量分塊或者分批次處理,有助於系統的正常穩定的執行。

最後,儘量提高一次請求的執行速度,垃圾回收越早越好,否則,大量的並行來了的時候,再來新的請求就無法分配記憶體了,就容易造成系統的雪崩。

2、java堆記憶體漏失

1)、問題描述

Java中的記憶體漏失是一些物件不再被應用程式使用但垃圾收集無法識別的情況。因此,這些未使用的物件仍然在Java堆空間中無限期地存在。不停的堆積最終會觸發java . lang.OutOfMemoryError。

2)、範例程式碼

當執行上面的程式碼時,可能會期望它永遠執行,不會出現任何問題,假設單純的快取解決方案只將底層對映擴充套件到10,000個元素,而不是所有鍵都已經在HashMap中。然而事實上元素將繼續被新增,因為key類並沒有重寫它的equals()方法。

隨著時間的推移,隨著不斷使用的洩漏程式碼,「快取」的結果最終會消耗大量Java堆空間。當洩漏記憶體填充堆區域中的所有可用記憶體時,垃圾收集無法清理它,java . lang.OutOfMemoryError。

3)、解決辦法

相對來說對應的解決方案比較簡單:重寫equals方法即可:

3.垃圾回收超時記憶體溢位

1)、問題描述 當應用程式耗盡所有可用記憶體時,GC開銷限制超過了錯誤,而GC多次未能清除它,這時便會引發java.lang.OutOfMemoryError。當JVM花費大量的時間執行GC,而收效甚微,而一旦整個GC的過程超過限制便會觸發錯誤(預設的jvm設定GC的時間超過98%,回收堆記憶體低於2%)。

2)、範例程式碼

3)、解決方法

要減少物件生命週期,儘量能快速的進行垃圾回收。

4.Metaspace記憶體溢位

1)、問題描述

元空間的溢位,系統會丟擲java.lang.OutOfMemoryError: Metaspace。出現這個異常的問題的原因是系統的程式碼非常多或參照的第三方包非常多或者通過動態程式碼生成類載入等方法,導致元空間的記憶體佔用很大。

2)、範例程式碼

3)、解決辦法

預設情況下,元空間的大小僅受本地記憶體限制。但是為了整機的效能,儘量還是要對該項進行設定,以免造成整機的服務停機。

  • 優化引數設定,避免影響其他JVM程序

-XX:MetaspaceSize,初始空間大小,達到該值就會觸發垃圾收集進行型別解除安裝,同時GC會對該值進行調整:如果釋放了大量的空間,就適當降低該值;如果釋放了很少的空間,那麼在不超過MaxMetaspaceSize時,適當提高該值。

-XX:MaxMetaspaceSize,最大空間,預設是沒有限制的。

除了上面兩個指定大小的選項以外,還有兩個與 GC 相關的屬性: -XX:MinMetaspaceFreeRatio,在GC之後,最小的Metaspace剩餘空間容量的百分比,減少為分配空間所導致的垃圾收集 。 -XX:MaxMetaspaceFreeRatio,在GC之後,最大的Metaspace剩餘空間容量的百分比,減少為釋放空間所導致的垃圾收集。

  • 慎重參照第三方包

對第三方包,一定要慎重選擇,不需要的包就去掉。這樣既有助於提高編譯打包的速度,也有助於提高遠端部署的速度。

  • 關注動態生成類的框架

對於使用大量動態生成類的框架,要做好壓力測試,驗證動態生成的類是否超出記憶體的需求會丟擲異常。

5、直接記憶體記憶體溢位

1)、問題描述

在使用ByteBuffer中的allocateDirect()的時候會用到,很多javaNIO(像netty)的框架中被封裝為其他的方法,出現該問題時會丟擲java.lang.OutOfMemoryError: Direct buffer memory異常。

如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時候,而不做clear的時候就會出現類似的問題。

2)、範例程式碼

3)、解決辦法

如果經常有類似的操作,可以考慮設定引數:-XX:MaxDirectMemorySize,並及時clear記憶體。

6、棧記憶體溢位

1)、問題描述

當一個執行緒執行一個Java方法時,JVM將建立一個新的棧幀並且把它push到棧頂。此時新的棧幀就變成了當前棧幀,方法執行時,使用棧幀來儲存引數、區域性變數、中間指令以及其他資料。

當一個方法遞迴呼叫自己時,新的方法所產生的資料(也可以理解為新的棧幀)將會被push到棧頂,方法每次呼叫自己時,會拷貝一份當前方法的資料並push到棧中。因此,遞迴的每層呼叫都需要建立一個新的棧幀。這樣的結果是,棧中越來越多的記憶體將隨著遞迴呼叫而被消耗,如果遞迴呼叫自己一百萬次,那麼將會產生一百萬個棧幀。這樣就會造成棧的記憶體溢位。

2)、範例程式碼

3)、解決辦法

如果程式中確實有遞迴呼叫,出現棧溢位時,可以調高-Xss大小,就可以解決棧記憶體溢位的問題了。遞迴呼叫防止形成死迴圈,否則就會出現棧記憶體溢位。

7、建立本地執行緒記憶體溢位

1)、問題描述

執行緒基本只佔用heap以外的記憶體區域,也就是這個錯誤說明除了heap以外的區域,無法為執行緒分配一塊記憶體區域了,這個要麼是記憶體本身就不夠,要麼heap的空間設定得太大了,導致了剩餘的記憶體已經不多了,而由於執行緒本身要佔用記憶體,所以就不夠用了。

2)、範例程式碼

3)、解決方法

首先檢查作業系統是否有執行緒數的限制,使用shell也無法建立執行緒,如果是這個問題就需要調整系統的最大可支援的檔案數。

日常開發中儘量保證執行緒最大數的可控制的,不要隨意使用執行緒池。不能無限制的增長下去。

8、超出交換區記憶體溢位

1)、問題描述

在Java應用程式啟動過程中,可以通過-Xmx和其他類似的啟動引數限制指定的所需的記憶體。而當JVM所請求的總記憶體大於可用實體記憶體的情況下,作業系統開始將內容從記憶體轉換為硬碟。

一般來說JVM會丟擲Out of swap space錯誤,代表應用程式向JVM native heap請求分配記憶體失敗並且native heap也即將耗盡時,錯誤訊息中包含分配失敗的大小(以位元組為單位)和請求失敗的原因。

2)、解決辦法

增加系統交換區的大小,我個人認為,如果使用了交換區,效能會大大降低,不建議採用這種方式,生產環境儘量避免最大記憶體超過系統的實體記憶體。其次,去掉系統交換區,只使用系統的記憶體,保證應用的效能。

9、陣列超限記憶體溢位

1)、問題描述 有的時候會碰到這種記憶體溢位的描述Requested array size exceeds VM limit,一般來說java對應用程式所能分配陣列最大大小是有限制的,只不過不同的平臺限制有所不同,但通常在1到21億個元素之間。當Requested array size exceeds VM limit錯誤出現時,意味著應用程式試圖分配大於Java虛擬機器器可以支援的陣列。JVM在為陣列分配記憶體之前,會執行特定平臺的檢查:分配的資料結構是否在此平臺是可定址的。

2)、範例程式碼

以下就是程式碼就是陣列超出了最大限制。

3)、解決方法

因此陣列長度要在平臺允許的長度範圍之內。不過這個錯誤一般少見的,主要是由於Java陣列的索引是int型別。 Java中的最大正整數為2 ^ 31 - 1 = 2,147,483,647。 並且平臺特定的限制可以非常接近這個數位,例如:我的環境上(64位元macOS,執行Jdk1.8)可以初始化陣列的長度高達2,147,483,645(Integer.MAX_VALUE-2)。若是在將陣列的長度再增加1達到nteger.MAX_VALUE-1會出現的OutOfMemoryError。

10、系統殺死程序記憶體溢位

1)、問題概述 在描述該問題之前,先熟悉一點作業系統的知識:作業系統是建立在程序的概念之上,這些程序在核心中作業,其中有一個非常特殊的程序,稱為「記憶體殺手(Out of memory killer)」。當核心檢測到系統記憶體不足時,OOM killer被啟用,檢查當前誰佔用記憶體最多然後將該程序殺掉。

一般Out of memory:Kill process or sacrifice child錯會在當可用虛擬虛擬記憶體(包括交換空間)消耗到讓整個作業系統面臨風險時,會被觸發。在這種情況下,OOM Killer會選擇「流氓程序」並殺死它。

2)、範例程式碼

3)、解決方法

雖然增加交換空間的方式可以緩解Java heap space異常,還是建議最好的方案就是升級系統記憶體,讓java應用有足夠的記憶體可用,就不會出現這種問題。

總結 通過以上的10種出現記憶體溢位情況,大家在實際碰到問題時也就會知道怎麼解決了,在實際編碼中也要記得:

  • 第三方jar包要慎重引入,堅決去掉沒有用的jar包,提高編譯的速度和系統的佔用記憶體。

  • 對於大的物件或者大量的記憶體申請,要進行優化,大的物件要分片處理,提高處理效能,減少物件生命週期。

  • 儘量固定執行緒的數量,保證執行緒佔用記憶體可控,同時需要大量執行緒時,要優化好作業系統的最大可開啟的連線數。

  • 對於遞迴呼叫,也要控制好遞迴的層級,不要太高,超過棧的深度。

  • 分配給棧的記憶體並不是越大越好,因為棧記憶體越大,執行緒多,留給堆的空間就不多了,容易丟擲OOM。JVM的預設引數一般情況沒有問題(包括遞迴)。

相關視訊教學推薦:Java視訊教學

以上就是java中記憶體漏失和記憶體溢位是什麼的詳細內容,更多請關注TW511.COM其它相關文章!