java中記憶體洩漏和記憶體溢出是什麼

記憶體洩漏是指程式在申請記憶體後，無法釋放已申請的記憶體空間。記憶體溢出是指程式申請記憶體時，沒有足夠的記憶體供申請者使用；或者說提供一塊儲存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中記憶體洩漏和記憶體溢出是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！