『JVM』我不想知道我是怎麼來滴，我就想知道我是怎麼沒滴

風的姿態發表於2020-11-05
JVM

我是風箏，公眾號「古時的風箏」，一個兼具深度與廣度的程式設計師鼓勵師，一個本打算寫詩卻寫起了程式碼的田園碼農！
文章會收錄在 JavaNewBee 中，更有 Java 後端知識圖譜，從小白到大牛要走的路都在裡面。

我們都知道 Java 程式都是跑在 JVM 上的，一旦 JVM 有什麼風吹草動，必然會影響服務的穩定性。幸運的話，服務會發生抖動，可能有部分請求出現延遲或異常。不幸的話，JVM 直接崩潰，導致服務完全中斷。

這可不是什麼好事，與 JVM 一起崩潰的，除了服務，還有我們的心態。

所謂的 JVM 崩潰，一般情況下就是指記憶體溢位，也就是 OutOfMemoryError 和 StackOverflowError。另外還有一種情況就是堆外記憶體佔用過大，這種情況會導致 JVM 所在機器的記憶體被撐爆，從而導致機器重啟等異常情況發生，我們把這種情況叫做記憶體洩漏。

那什麼情況下會造成 JVM 崩潰呢，有哪幾種型別的崩潰呢？俗話說，知己知彼，方能百戰不殆。瞭解了發生崩潰的原因，才能更好的解決 JVM 崩潰問題。

image-20201016165948638

首先還是放出 JVM 記憶體模型圖，JVM 要理解起來是很抽象的，藉助下面這張圖可以具象化的瞭解 JVM 記憶體模型，而發生溢位的幾個部分都可以在圖中找到。在 JDK 8 中，永久代已經不存在了，取而代之的是元空間（metaspace）。

image-20201019183925854

下面就以 Hotspot JDK 8 為背景，看一下 JVM 記憶體溢位和記憶體洩漏的幾種情況。

首先設定 JVM 啟動引數，限制堆空間大小，堆空間設定為 20M，其中新生代10M，元空間10M，並指定垃圾收集演算法採用 CMS 演算法。之後的例子都會使用這套引數。

-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:+CMSClassUnloadingEnabled
-XX:+ParallelRefProcEnabled
-XX:+CMSScavengeBeforeRemark
-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:+HeapDumpOnOutOfMemoryError
-XX:MetaspaceSize=10M
-XX:MaxMetaspaceSize=10M
-XX:HeapDumpPath=/Users/fengzheng/jvmlog

堆溢位

堆溢位，應該是最常見的一種記憶體溢位的場景了。JVM 中分配絕大多數物件例項和陣列都存在堆上，另外堆記憶體也是垃圾收集器工作的主要戰場。

當我們的 Java 程式啟動的時候，會指定堆空間的大小，新建物件和陣列的時候會分配到堆上面，當新物件申請空間的時候，如果堆記憶體不夠了，就會發生垃圾收集動作，大多數時候會發生在新生代，叫做 Minor GC。當新生代回收完成，空間仍然不夠的話，會發生一次 FullGC。FullGC 後，空間仍然不夠，此時就會發生 OOM 錯誤，也就是堆溢位。

模擬一下這個場景

private final static int _1K = 1024;

public static void main(String[] args){
  List<byte[]> byteList = new ArrayList<>();
  quietlyWaitingForCrashHeap(byteList);
}

public static void quietlyWaitingForCrashHeap(List<byte[]> byteList) {
  try {
    while (true) {
      byteList.add(new byte[500 * _1K]);
      //Thread.sleep(1000);
      Thread.sleep(100);
    }
  } catch (InterruptedException e) {

  }
}

上面的方法會持續的向List<byte[]>陣列中每次新增500k的元素，整個堆只有20M，可想而知，程式一執行起來，馬上就會將對空間填滿，導致後面的元素加不進去，而又回收不掉，從而導致堆記憶體溢位。

下面是程式執行之後的結果，經過垃圾回收最終還是沒有多餘的空間，從而發生 java.lang.OutOfMemoryError: Java heap space異常。

image-20201016211017630

發生堆記憶體溢位的根本原因就是使用中的物件大小超過了堆記憶體大小。

堆記憶體空間設定的太小，要根據預估的實際使用堆大小合理的設定堆空間設定。

程式有漏洞導致，某些靜態變數持續的增大，例如快取資料錯誤的初始化，導致快取無止境的增加，最終導致堆記憶體溢位。針對這種情況，恐怕沒什麼好方法，除了做好測試之外，就是在問題發生後做好日誌分析。

棧溢位

虛擬機器棧是用來儲存區域性變數表、運算元棧、動態連結、方法出口等資訊的，每呼叫一個 Java 方法就會為此方法在虛擬機器棧中生成棧幀。

棧除了包括虛擬機器棧之外，還包括本地方法棧，當呼叫的方法是本地方法（例如 C 語言實現的方法）時，會用到本地方法棧。不過，在 HotSpot 虛擬機器中，虛擬機器棧和本地方法棧被合二為一了。

模擬棧溢位場景

public static void main(String[] args){
  stackOverflow();
}

/**
* stackoverflow
*/
public static void stackOverflow() {
  stackOverflow();
}

在上面的程式碼中，stackOverflow() 方法的呼叫是一個無限遞迴的過程，沒有遞迴出口。前面說了，每呼叫一個方法就會在虛擬機器棧中生成棧幀，無限的遞迴，必定造成無限的生成棧幀，最後導致棧空間被填滿，從而發生溢位。

image-20201019122447325

上面模擬了最常見的一種狀況，產生這種狀況的原因很可能是由於程式 bug 導致的，一般來說，遞迴必定會有遞迴出口，如果由於某些原因導致了程式在執行的過程中無法達到出口條件，那就會造成這種異常。還有就是迴圈體，迴圈體的迴圈次數如果過大，也有可能出現棧溢位。

另外還可能是其他比較不容易出現的原因，比如建立的執行緒數過多，執行緒建立要在虛擬機器棧中分配空間，如果建立執行緒過多，可能會出現 OutOfMemoryError異常，但是一般來說，都會用執行緒池的方法代替手動建立執行緒的方式，所以，這種情況不容易出現。

元空間溢位

用於儲存已被虛擬機器載入的類資訊，常量，靜態變數，即時編譯(JIT)後的程式碼等資料，在 JDK 8 中，已經用 metaSpace 代替了永久代的。預設情況下 metaSpace 的大小是沒有限制的，也就是所在伺服器的實際記憶體大小，但是，一般情況下，最好還是設定元空間的大小。

一般在產生大量動態生成類的情景中，可能會出現元空間的記憶體溢位。

模擬元空間溢位

public static void main(String[] args){
  List<byte[]> byteList = new ArrayList<>();
  //quietlyWaitingForCrashHeap(byteList);
  // stackOverflow();
  methodAreaOverflow();
}

public static void methodAreaOverflow() {
  int i = 0;
  while (true) {
    Enhancer enhancer = new Enhancer();
    enhancer.setUseCache(false);
    enhancer.setSuperclass(MethodOverflow.class);
    enhancer.setCallback(new MethodInterceptor() {
      @Override
      public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        return methodProxy.invokeSuper(o, objects);
      }
    });
    enhancer.create();
    System.out.println(++i);
  }
}

通過 CGLIB 的方式動態的建立很多個動態類，這樣一來，類資訊就會越來越多的存到元空間，從而導致元空間溢位。

image-20201019163227576

例如在使用 Spring、 MyBatis 等技術框架的時候會動態建立 Bean 例項類，另外，Spring AOP 也會產生動態代理類。

堆外記憶體溢位

大多數情況下，記憶體都會在 JVM 堆記憶體中分配，很少情況下需要直接在堆外分配記憶體空間。使用堆外記憶體的幾個好處是：

  • 在程式間可以共享，減少虛擬機器間的複製
  • 對垃圾回收停頓的改善：如果應用某些長期存活並大量存在的物件，經常會出發YGC或者FullGC，可以考慮把這些物件放到堆外。過大的堆會影響Java應用的效能。如果使用堆外記憶體的話，堆外記憶體是直接受作業系統管理( 而不是虛擬機器 )。這樣做的結果就是能保持一個較小的堆內記憶體，以減少垃圾收集對應用的影響。
  • 在某些場景下可以提升程式I/O操縱的效能。少去了將資料從堆內記憶體拷貝到堆外記憶體的步驟。

通常在需要大量頻繁的進行 IO 操作的時候會用到堆外記憶體，例如 Netty、RocketMQ 等使用到了堆外記憶體，目的就是為了加快速度。

所以，在出現系統記憶體佔用過大的情況時，排查堆疊無果後，可以看一下堆外記憶體的使用情況，看看是不是堆外記憶體溢位了。

總結

事前做好配置

JVM 問題本身就是比較抽象和難以直觀發現的，所以在專案上線前除了做好程式碼邏輯的測試外，還要對 JVM 引數進行合理配置，根據應用程式的體量和特點選擇好合適的引數，比如堆疊大小、垃圾收集器種類等等。

另外，垃圾收集日誌一定要有保留，還有就是發生記憶體溢位時要儲存 dump 檔案。

事中做好監控

在程式上線執行的過程中，做好 JVM 的監控工作，比如用 Spring Admin 這種比較輕量的監控工具，或者大型專案用 Cat、SkyWallking 等這些分散式鏈路監控系統。

事後做好現場保護和分析

再合理的引數配置和監控平臺，也難免不發生異常，這也是很正常的，不出現異常才有問題好吧。在發生異常之後，要及時的保留現場，如果是多例項應用，可以暫時將發生異常的例項做下線處理，然後再進行問題的排查。如果是單例項的服務，那要及時的確認最新的日誌和dump已經留存好，確認完成後，再採取錯誤讓服務重啟。

這位英俊瀟灑的少年，如果覺得還不錯的話，給個推薦可好！

公眾號「古時的風箏」，Java 開發者，全棧工程師，bug 殺手，擅長解決問題。
一個兼具深度與廣度的程式設計師鼓勵師，本打算寫詩卻寫起了程式碼的田園碼農！堅持原創乾貨輸出，你可選擇現在就關注我，或者看看歷史文章再關注也不遲。長按二維碼關注，跟我一起變優秀！

相關文章