內存泄漏是指程序在申請內存后，無法釋放已申請的內存空間。內存溢出是指程序申請內存時，沒有足夠的內存供申請者使用；或者說提供一塊存儲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視頻教程