[[347298]]

我們都知道 Java 程序都是跑在 JVM 上的，一旦 JVM 有什么風(fēng)吹草動(dòng)，必然會(huì)影響服務(wù)的穩(wěn)定性。幸運(yùn)的話，服務(wù)會(huì)發(fā)生抖動(dòng)，可能有部分請(qǐng)求出現(xiàn)延遲或異常。不幸的話，JVM 直接崩潰，導(dǎo)致服務(wù)完全中斷。

這可不是什么好事，與 JVM 一起崩潰的，除了服務(wù)，還有我們的心態(tài)。

所謂的 JVM 崩潰，一般情況下就是指內(nèi)存溢出，也就是 OutOfMemoryError 和 StackOverflowError。另外還有一種情況就是堆外內(nèi)存占用過大，這種情況會(huì)導(dǎo)致 JVM 所在機(jī)器的內(nèi)存被撐爆，從而導(dǎo)致機(jī)器重啟等異常情況發(fā)生，我們把這種情況叫做內(nèi)存泄漏。

那什么情況下會(huì)造成 JVM 崩潰呢，有哪幾種類型的崩潰呢?俗話說，知己知彼，方能百戰(zhàn)不殆。了解了發(fā)生崩潰的原因，才能更好的解決 JVM 崩潰問題。

首先還是放出 JVM 內(nèi)存模型圖，JVM 要理解起來是很抽象的，借助下面這張圖可以具象化的了解 JVM 內(nèi)存模型，而發(fā)生溢出的幾個(gè)部分都可以在圖中找到。在 JDK 8 中，永久代已經(jīng)不存在了，取而代之的是元空間(metaspace)。

下面就以 Hotspot JDK 8 為背景，看一下 JVM 內(nèi)存溢出和內(nèi)存泄漏的幾種情況。

首先設(shè)置 JVM 啟動(dòng)參數(shù)，限制堆空間大小，堆空間設(shè)置為 20M，其中新生代10M，元空間10M，并指定垃圾收集算法采用 CMS 算法。之后的例子都會(huì)使用這套參數(shù)。

-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 

堆溢出

堆溢出，應(yīng)該是最常見的一種內(nèi)存溢出的場(chǎng)景了。JVM 中分配絕大多數(shù)對(duì)象實(shí)例和數(shù)組都存在堆上，另外堆內(nèi)存也是垃圾收集器工作的主要戰(zhàn)場(chǎng)。

當(dāng)我們的 Java 程序啟動(dòng)的時(shí)候，會(huì)指定堆空間的大小，新建對(duì)象和數(shù)組的時(shí)候會(huì)分配到堆上面，當(dāng)新對(duì)象申請(qǐng)空間的時(shí)候，如果堆內(nèi)存不夠了，就會(huì)發(fā)生垃圾收集動(dòng)作，大多數(shù)時(shí)候會(huì)發(fā)生在新生代，叫做 Minor GC。當(dāng)新生代回收完成，空間仍然不夠的話，會(huì)發(fā)生一次 FullGC。FullGC 后，空間仍然不夠，此時(shí)就會(huì)發(fā)生 OOM 錯(cuò)誤，也就是堆溢出。

模擬一下這個(gè)場(chǎng)景

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) { 
 
  } 
} 

上面的方法會(huì)持續(xù)的向List

下面是程序運(yùn)行之后的結(jié)果，經(jīng)過垃圾回收最終還是沒有多余的空間，從而發(fā)生 java.lang.OutOfMemoryError: Java heap space異常。

image-20201016211017630

發(fā)生堆內(nèi)存溢出的根本原因就是使用中的對(duì)象大小超過了堆內(nèi)存大小。

堆內(nèi)存空間設(shè)置的太小，要根據(jù)預(yù)估的實(shí)際使用堆大小合理的設(shè)置堆空間設(shè)置。

程序有漏洞導(dǎo)致，某些靜態(tài)變量持續(xù)的增大，例如緩存數(shù)據(jù)錯(cuò)誤的初始化，導(dǎo)致緩存無止境的增加，最終導(dǎo)致堆內(nèi)存溢出。針對(duì)這種情況，恐怕沒什么好方法，除了做好測(cè)試之外，就是在問題發(fā)生后做好日志分析。

棧溢出

虛擬機(jī)棧是用來存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息的，每調(diào)用一個(gè) Java 方法就會(huì)為此方法在虛擬機(jī)棧中生成棧幀。

棧除了包括虛擬機(jī)棧之外，還包括本地方法棧，當(dāng)調(diào)用的方法是本地方法(例如 C 語言實(shí)現(xiàn)的方法)時(shí)，會(huì)用到本地方法棧。不過，在 HotSpot 虛擬機(jī)中，虛擬機(jī)棧和本地方法棧被合二為一了。

模擬棧溢出場(chǎng)景

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

在上面的代碼中，stackOverflow() 方法的調(diào)用是一個(gè)無限遞歸的過程，沒有遞歸出口。前面說了，每調(diào)用一個(gè)方法就會(huì)在虛擬機(jī)棧中生成棧幀，無限的遞歸，必定造成無限的生成棧幀，最后導(dǎo)致?？臻g被填滿，從而發(fā)生溢出。

image-20201019122447325

上面模擬了最常見的一種狀況，產(chǎn)生這種狀況的原因很可能是由于程序 bug 導(dǎo)致的，一般來說，遞歸必定會(huì)有遞歸出口，如果由于某些原因?qū)е铝顺绦蛟趫?zhí)行的過程中無法達(dá)到出口條件，那就會(huì)造成這種異常。還有就是循環(huán)體，循環(huán)體的循環(huán)次數(shù)如果過大，也有可能出現(xiàn)棧溢出。

另外還可能是其他比較不容易出現(xiàn)的原因，比如創(chuàng)建的線程數(shù)過多，線程創(chuàng)建要在虛擬機(jī)棧中分配空間，如果創(chuàng)建線程過多，可能會(huì)出現(xiàn) OutOfMemoryError異常，但是一般來說，都會(huì)用線程池的方法代替手動(dòng)創(chuàng)建線程的方式，所以，這種情況不容易出現(xiàn)。

元空間溢出用于存儲(chǔ)已被虛擬機(jī)加載的類信息，常量，靜態(tài)變量，即時(shí)編譯(JIT)后的代碼等數(shù)據(jù)，在 JDK 8 中，已經(jīng)用 metaSpace 代替了永久代的。默認(rèn)情況下 metaSpace 的大小是沒有限制的，也就是所在服務(wù)器的實(shí)際內(nèi)存大小，但是，一般情況下，最好還是設(shè)置元空間的大小。

一般在產(chǎn)生大量動(dòng)態(tài)生成類的情景中，可能會(huì)出現(xiàn)元空間的內(nèi)存溢出。

模擬元空間溢出

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 的方式動(dòng)態(tài)的創(chuàng)建很多個(gè)動(dòng)態(tài)類，這樣一來，類信息就會(huì)越來越多的存到元空間，從而導(dǎo)致元空間溢出。

image-20201019163227576

例如在使用 Spring、 MyBatis 等技術(shù)框架的時(shí)候會(huì)動(dòng)態(tài)創(chuàng)建 Bean 實(shí)例類，另外，Spring AOP 也會(huì)產(chǎn)生動(dòng)態(tài)代理類。

堆外內(nèi)存溢出

大多數(shù)情況下，內(nèi)存都會(huì)在 JVM 堆內(nèi)存中分配，很少情況下需要直接在堆外分配內(nèi)存空間。使用堆外內(nèi)存的幾個(gè)好處是：

• 在進(jìn)程間可以共享，減少虛擬機(jī)間的復(fù)制
• 對(duì)垃圾回收停頓的改善：如果應(yīng)用某些長(zhǎng)期存活并大量存在的對(duì)象，經(jīng)常會(huì)觸發(fā)YGC或者FullGC，可以考慮把這些對(duì)象放到堆外。過大的堆會(huì)影響Java應(yīng)用的性能。如果使用堆外內(nèi)存的話，堆外內(nèi)存是直接受操作系統(tǒng)管理( 而不是虛擬機(jī) )。這樣做的結(jié)果就是能保持一個(gè)較小的堆內(nèi)內(nèi)存，以減少垃圾收集對(duì)應(yīng)用的影響。
• 在某些場(chǎng)景下可以提升程序I/O操縱的性能。少去了將數(shù)據(jù)從堆內(nèi)內(nèi)存拷貝到堆外內(nèi)存的步驟。

通常在需要大量頻繁的進(jìn)行 IO 操作的時(shí)候會(huì)用到堆外內(nèi)存，例如 Netty、RocketMQ 等使用到了堆外內(nèi)存，目的就是為了加快速度。

所以，在出現(xiàn)系統(tǒng)內(nèi)存占用過大的情況時(shí)，排查堆棧無果后，可以看一下堆外內(nèi)存的使用情況，看看是不是堆外內(nèi)存溢出了。

總結(jié)

事前做好配置

JVM 問題本身就是比較抽象和難以直觀發(fā)現(xiàn)的，所以在項(xiàng)目上線前除了做好代碼邏輯的測(cè)試外，還要對(duì) JVM 參數(shù)進(jìn)行合理配置，根據(jù)應(yīng)用程序的體量和特點(diǎn)選擇好合適的參數(shù)，比如堆棧大小、垃圾收集器種類等等。

另外，垃圾收集日志一定要有保留，還有就是發(fā)生內(nèi)存溢出時(shí)要保存 dump 文件。

事中做好監(jiān)控

在程序上線運(yùn)行的過程中，做好 JVM 的監(jiān)控工作，比如用 Spring Admin 這種比較輕量的監(jiān)控工具，或者大型項(xiàng)目用 Cat、SkyWallking 等這些分布式鏈路監(jiān)控系統(tǒng)。

事后做好現(xiàn)場(chǎng)保護(hù)和分析

再合理的參數(shù)配置和監(jiān)控平臺(tái)，也難免不發(fā)生異常，這也是很正常的，不出現(xiàn)異常才有問題好吧。在發(fā)生異常之后，要及時(shí)的保留現(xiàn)場(chǎng)，如果是多實(shí)例應(yīng)用，可以暫時(shí)將發(fā)生異常的實(shí)例做下線處理，然后再進(jìn)行問題的排查。如果是單實(shí)例的服務(wù)，那要及時(shí)的確認(rèn)最新的日志和dump已經(jīng)留存好，確認(rèn)完成后，再采取錯(cuò)誤讓服務(wù)重啟。

 本文轉(zhuǎn)載自微信公眾號(hào)「古時(shí)的風(fēng)箏」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系古時(shí)的風(fēng)箏公眾號(hào)。