從JVM模型談十種記憶體溢位的解決方法
導言：
對於java程式員來說，在虛擬機器自動記憶體管理機制的幫助下，不需要自己實現釋放記憶體，不容易出現記憶體洩漏和記憶體溢位的問題，由虛擬機器管理記憶體這一切看起來非常美好，但是一旦出現記憶體溢位或者記憶體洩漏的問題，對於不熟悉jvm虛擬機器是怎麼使用記憶體的話，那麼排查錯誤將會是一項非常艱鉅的任務。所以在瞭解記憶體溢位之前先要搞明白JVM的記憶體模型。
JVM（Java虛擬機器）是一個抽象的計算模型。就如同一臺真實的機器，它有自己的指令集和執行引擎，可以在執行時操控記憶體區域。目的是為構建在其上執行的應用程式提供一個執行環境。JVM可以解讀指令程式碼並與底層進行互動：包括作業系統平臺和執行指令並管理資源的硬體體系結構。
JVM記憶體模型
根據 JVM8 規範，JVM 執行時記憶體共分為虛擬機器棧、堆、元空間、程式計數器、本地方法棧五個部分。還有一部分記憶體叫直接記憶體，屬於作業系統的本地記憶體，也是可以直接操作的。
1. 元空間(Metaspace）
元空間的本質和永久代類似，都是對JVM規範中方法區的實現。不過元空間與永久代之間最大的區別在於：元空間並不在虛擬機器中，而是使用本地記憶體。
2.虛擬機器棧(JVM Stacks）
每個執行緒有一個私有的棧，隨著執行緒的建立而建立。棧裡面存著的是一種叫“棧幀”的東西，每個方法會建立一個棧幀，棧幀中存放了區域性變量表（基本資料型別和物件引用）、運算元棧、方法出口等資訊。棧的大小可以固定也可以動態擴充套件。
3. 本地方法棧(Native Method Stack)
與虛擬機器棧類似，區別是虛擬機器棧執行java方法，本地方法站執行native方法。在虛擬機器規範中對本地方法棧中方法使用的語言、使用方法與資料結構沒有強制規定，因此虛擬機器可以自由實現它。
4. 程式計數器(Program Counter Register)
程式計數器可以看成是當前執行緒所執行的位元組碼的行號指示器。在任何一個確定的時刻，一個處理器（對於多核心來說是一個核心）都只會執行一條執行緒中的指令。因此，為了執行緒切換後能恢復到正確的執行位置，每條執行緒都需要一個獨立的程式計數器，我們稱這類記憶體區域為“執行緒私有”記憶體。
5.堆記憶體(Heap)
堆記憶體是 JVM 所有執行緒共享的部分，在虛擬機器啟動的時候就已經建立。所有的物件和陣列都在堆上進行分配。這部分空間可通過 GC 進行回收。當申請不到空間時會丟擲 OutOfMemoryError。堆是JVM記憶體佔用最大，管理最複雜的一個區域。其唯一的用途就是存放物件例項：所有的物件例項及陣列都在對上進行分配。jdk1.8後，字串常量池從永久代中剝離出來，存放在其中。
6.直接記憶體(Direct Memory)
直接記憶體並不是虛擬機器執行時資料區的一部分，也不是Java 虛擬機器規範中農定義的記憶體區域。在JDK1.4 中新加入了IO/">NIO(New Input/Output)類，引入了一種基於通道(Channel)與緩衝區（Buffer）的I/O 方式，它可以使用native 函式庫直接分配堆外記憶體，然後通脫一個儲存在Java堆中的DirectByteBuffer 物件作為這塊記憶體的引用進行操作。這樣能在一些場景中顯著提高效能，因為避免了在Java堆和Native堆中來回複製資料。
記憶體溢位的十個場景
JVM執行時首先需要類載入器（classLoader）載入所需類的位元組碼檔案。載入完畢交由執行引擎執行，在執行過程中需要一段空間來儲存資料（類比CPU與主存）。這段記憶體空間的分配和釋放過程正是我們需要關心的執行時資料區。記憶體溢位的情況就是從類載入器載入的時候開始出現的，記憶體溢位分為兩大類：OutOfMemoryError和StackOverflowError。以下舉出10個記憶體溢位的情況，並通過例項程式碼的方式講解了是如何出現記憶體溢位的。
1.java堆記憶體溢位
當出現java.lang.OutOfMemoryError:Java heap space異常時，就是堆記憶體溢位了。
1.問題描述
1.設定的jvm記憶體太小，物件所需記憶體太大，建立物件時分配空間，就會丟擲這個異常。
2.流量/資料峰值，應用程式自身的處理存在一定的限額，比如一定數量的使用者或一定數量的資料。而當用戶數量或資料量突然激增並超過預期的閾值時，那麼就會峰值停止前正常執行的操作將停止並觸發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.示例程式碼
以下是用迴圈動態生成class的方式來模擬元空間的記憶體溢位的。
3.如何解決元空間的記憶體溢位呢？
預設情況下，元空間的大小僅受本地記憶體限制。但是為了整機的效能，儘量還是要對該項進行設定，以免造成整機的服務停機。
1）優化引數配置，避免影響其他JVM程序
-XX:MetaspaceSize，初始空間大小，達到該值就會觸發垃圾收集進行型別解除安裝，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那麼在不超過MaxMetaspaceSize時，適當提高該值。
-XX:MaxMetaspaceSize，最大空間，預設是沒有限制的。
除了上面兩個指定大小的選項以外，還有兩個與 GC 相關的屬性：
-XX:MinMetaspaceFreeRatio，在GC之後，最小的Metaspace剩餘空間容量的百分比，減少為分配空間所導致的垃圾收集 。
-XX:MaxMetaspaceFreeRatio，在GC之後，最大的Metaspace剩餘空間容量的百分比，減少為釋放空間所導致的垃圾收集。
2）慎重引用第三方包
對第三方包，一定要慎重選擇，不需要的包就去掉。這樣既有助於提高編譯打包的速度，也有助於提高遠端部署的速度。
3）關注動態生成類的框架
對於使用大量動態生成類的框架，要做好壓力測試，驗證動態生成的類是否超出記憶體的需求會丟擲異常。
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的空間設定得太大了，導致了剩餘的記憶體已經不多了，而由於執行緒本身要佔用記憶體，所以就不夠用了。
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種出現記憶體溢位情況，大家在實際碰到問題時也就會知道怎麼解決了，在實際編碼中也要記得：
1.第三方jar包要慎重引入，堅決去掉沒有用的jar包，提高編譯的速度和系統的佔用記憶體。
2.對於大的物件或者大量的記憶體申請，要進行優化，大的物件要分片處理，提高處理效能，減少物件生命週期。
3.儘量固定執行緒的數量，保證執行緒佔用記憶體可控，同時需要大量執行緒時，要優化好作業系統的最大可開啟的連線數。
4.對於遞迴呼叫，也要控制好遞迴的層級，不要太高，超過棧的深度。
5.分配給棧的記憶體並不是越大越好，因為棧記憶體越大，執行緒多，留給堆的空間就不多了，容易丟擲OOM。JVM的預設引數一般情況沒有問題（包括遞迴）。
———— / END / ————