文章開篇問一個問題吧，一個java程序，如果其中一個線程發生了OOM，那進程中的其他線程還能運行嗎？

接下來做實驗，看看JVM的六種OOM之后程序還能不能訪問。

在這里我用的是一個springboot程序。

/*** @author ：charon* @date ：Created in 2021/5/17 8:30* @description ： 程序啟動類* @version: 1.0*/ @SpringBootApplication public class CharonApplication {public static void main(String[] args) {SpringApplication.run(CharonApplication.class, args);}}

監測服務是否可用（http://localhost:8080/checkHealth?測試服務正常可用）：

/*** @author ：charon* @date ：Created in 2021/5/17 8:49* @description ： 測試服務是否可用* @version: 1.0*/ @RestController public class CheckHealthController {@RequestMapping("/checkHealth")public String stackOverFlowError(){System.out.println("調用服務監測接口-----------------------");return "服務監測接口返回";} }

1.StackOverflowError（棧溢出）

棧溢出代表的是：當棧的深度超過虛擬機分配給線程的棧大小時就會出現error。

/*** @author ：charon* @date ：Created in 2021/5/17 8:49* @description ： 測試java.lang.StackOverflowError: null的錯誤* @version: 1.0*/ @RestController public class StackOverFlowErrorController {/*** 遞歸調用一個方法，使其超過棧的最大深度*/@RequestMapping("/stackOverFlowError")public void stackOverFlowError(){stackOverFlowError();} }

使用瀏覽器調用棧溢出的接口（localhost:8080/stackOverFlowError），發現后臺報了棧溢出的錯誤。

調用監測程序可用的接口，發現還是可以正常訪問。

2.Java heap space（堆內存溢出）

當GC多次的時候新生代和老生代的堆內存幾乎用滿了，頻繁觸發Full GC (Ergonomics) ，直到沒有內存空間給新生對象了。所以JVM拋出了內存溢出錯誤！進而導致程序崩潰。

設置虛擬機參數（-Xms10m -Xmx10m -XX:+PrintGCDetails），如果不設置的話，可能會執行很久。

@RestController public class JavaHeapSpaceController {/*** 使用是循環創建對象，是堆內存溢出*/@RequestMapping("/javaHeapSpace")public void javaHeapSpace(){String str = "hello world";while (true){str += new Random().nextInt(1111111111) + new Random().nextInt(222222222);/*** intern()方法：* （1）當常量池中不存在這個字符串的引用，將這個對象的引用加入常量池，返回這個對象的引用。* （2）當常量池中存在這個字符串的引用，返回這個對象的引用；*/str.intern();}} }

調用監測程序可用的接口，發現還是可以正常訪問。

3.direct buffer memory

在寫IO程序（如Netty）的時候，經常使用ByteBuffer來讀取或者寫入數據，這是一種基于通道（channel）和緩沖區（Buffer）的IO方式，他可以使用Native函數庫直接分配對外內存，然后通過一個存儲在java堆里面的DirectByteBuffer對象作為這塊內存的引用操作，這樣能在在一些場景中顯著提高性能，因為避免了再java堆和Native堆中來回復制數據。

ByteBuffer.allocate(capacity) 這種方式是分配jvm堆內存，屬于GC管轄的范圍，由于需要拷貝所以速度較慢
ByteBuffer.allocateDirect(capacity) 這種方式是分配本地內存，不屬于GC的管轄范圍，由于不需要內存拷貝，所以速度較快

但是如果不斷分配本地內存，堆內存很少使用，那么JVM就不需要執行GC，DirectByteBuffer對象就不會回收，
這時候堆內存充足，但本地內存可能已經使用光了，再次嘗試分配本地內存，就會出現OutOfMemoryError

設置JVM參數: -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m

@RestController public class DirectBufferMemoryController {@RequestMapping("/directBufferMemory")public void directBufferMemory(){System.out.println("初始配置的最大本地內存為："+ (sun.misc.VM.maxDirectMemory()/1024/1024)+"MB");// 在jvm參數里設置的最大內存為5M，ByteBuffer buffer = ByteBuffer.allocateDirect(6*1024*1024);}}

訪問內存溢出的接口（http://localhost:8080/directBufferMemory），報錯之后再次訪問服務監測接口，發現還是可以繼續訪問的。

4.GC overhead limit exceeded

GC回收之間過長會拋出這個錯，過長的定義是：超過98%的時間用來做垃圾回收并且只回收了不到2%的堆內存，連續多次GC都只回收了不到2%的極端情況下才會拋出，加入不拋出GC overhead limit錯誤，就會發生下列情況：

• GC清理的這么點內存很快就會再次被填滿，形成惡性循環
• CPU使用率一直是100%，而GC沒有任何效果

設置JVM參數: -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m

@RestController public class GcOverHeadController {@RequestMapping("/gcOverHead")public void gcOverHead(){int i = 0;List<String> list = new ArrayList<>();try{while(true){list.add(String.valueOf(++i).intern());}}catch(Throwable e){System.out.println("i的值為：" + i);e.printStackTrace();throw e;}} }

如下圖所示，在報錯這個異常之前，在頻繁的Full GC，但是垃圾回收前后，新生代和老年代的內存差不多，就說明，垃圾回收效果不大。

再次訪問服務監測接口，發現還是可以繼續訪問的。

5.Metaspace

java 8及其以后的版本中使用了MetaSpace代替了永久代，它與永久代最大的區別在于：

? MetaSpace并不在虛擬機內存中，而是使用本地內存，也就是說，在java8中，Class metadata被存儲在MetaSpace的native Memory中

MetaSpace中存儲了一下信息：

• 虛擬機加載的類信息
• 常量池
• 靜態變量
• 即時編譯后的代碼

參數設置：-XX:+PrintGCDetails -XX:MetaspaceSize=50m -XX:MaxMetaspaceSize=50m

@RestController public class MetaSpaceController {static class OomTest{}/*** 模擬MetaSpace溢出，不斷生成類往元空間放，類占據的空間會超過MetaSpace指定的大小*/@RequestMapping("/metaSpace")public void metaSpace(){int i = 0;try{while (true){i++;/*** Enhancer允許為非接口類型創建一個java代理。Enhancer動態創建了給定類型的子類但是攔截了所有的方法，* 和proxy不一樣的是：不管是接口還是類它都能正常工作。*/Enhancer enhancer = new Enhancer();enhancer.setSuperclass(OomTest.class);enhancer.setUseCache(false);enhancer.setCallback(new MethodInterceptor() {@Overridepublic Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {return methodProxy.invokeSuper(o,objects);}});enhancer.create();}}catch (Throwable e){System.out.println("i的值為：" + i);e.printStackTrace();}} }

我記得之前看過一篇公眾號的文章，就是使用Fastjson創建的代理類導致的Metaspace的問題，具體地址我也忘記了。。。。。

再次訪問服務監測接口，發現還是可以繼續訪問的。

6.unable to create new thread

在高并發服務時，經常會出現如下錯誤，

導致原因：

• 1.應用程序創建了太多的線程，一個應用進程創建的線程超過了系統承載極限
• 2.服務器不允許應用程序創建這么多線程，linux系統默認允許單個進程可以創建的線程數為1024個（如果是普通用戶小于這個值）

解決辦法：

• 1.降低應用程序創建線程的數量，分析應用是否真的需要創建這么多線程
• 2.對于有的應用確實需要創建這么多的線程，可以修改linux服務器配置，擴大linux的默認限制

查看：ulimit -u

修改：vim /etc/security/limits.d/90-nproc.conf

@RestController public class UnableCreateThreadController {/*** 友情提示:千萬別在windows中運行這段代碼，如果不小心和我一樣試了，那就只能強制重啟了*/@RequestMapping("/unableCreateThread")public void unableCreateThread(){for (int i = 0; ; i++) {System.out.println("i的值為：" + i);new Thread(()->{try{Thread.sleep(1000*1000);} catch (InterruptedException e){e.printStackTrace();}}).start();}} }

我這里是使用的root用戶測試的，創建了7409個線程。大家測試的時候最好是使用普通用戶測試。

最后執行檢測服務的接口，發現程序還是可以繼續訪問的。

小結

其實發生OOM的線程一般情況下會死亡，也就是會被終結掉，該線程持有的對象占用的heap都會被gc了，釋放內存。因為發生OOM之前要進行gc，就算其他線程能夠正常工作，也會因為頻繁gc產生較大的影響。

總結

以上是生活随笔為你收集整理的高德面试官问我：JVM内存溢出后服务还能运行吗，我一顿操作行云流水的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。