出處: https://mp.weixin.qq.com/s/8j8YTcr2qhVActLGzOqe7Q
https://blog.csdn.net/h2604396739/article/details/91441248
先分析一道面試題
JVM 堆內存溢出后,其他線程是否可繼續工作?
答:這道題其實很有難度,涉及的知識點有jvm內存分配、作用域、gc等,不是簡單的是與否的問題。
由於題目中給出的OOM,java中OOM又分很多類型;比如:堆溢出(“java.lang.OutOfMemoryError: Java heap space”)、永久帶溢出(“java.lang.OutOfMemoryError:Permgen space”)、不能創建線程(“java.lang.OutOfMemoryError:Unable to create new native thread”)等很多種情況。
本文主要是分析堆溢出對應用帶來的影響。
先說一下答案,答案是還能運行。
代碼如下:
public class JvmThread { public static void main(String[] args) { new Thread(() -> { List<byte[]> list = new ArrayList<byte[]>(); while (true) { System.out.println(new Date().toString() + Thread.currentThread() + "=="); byte[] b = new byte[1024 * 1024 * 1]; list.add(b); try { Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); } } }).start(); // 線程二 new Thread(() -> { while (true) { System.out.println(new Date().toString() + Thread.currentThread() + "=="); try { Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); } } }).start(); } }
結果展示:
Wed Nov 07 14:42:18 CST 2018Thread[Thread-1,5,main]== Wed Nov 07 14:42:18 CST 2018Thread[Thread-0,5,main]== Wed Nov 07 14:42:19 CST 2018Thread[Thread-1,5,main]== Wed Nov 07 14:42:19 CST 2018Thread[Thread-0,5,main]== Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space at com.gosaint.util.JvmThread.lambda$main$0(JvmThread.java:21) at com.gosaint.util.JvmThread$$Lambda$1/521645586.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) Wed Nov 07 14:42:20 CST 2018Thread[Thread-1,5,main]== Wed Nov 07 14:42:21 CST 2018Thread[Thread-1,5,main]== Wed Nov 07 14:42:22 CST 2018Thread[Thread-1,5,main]==
JVM啟動參數設置:
上圖是JVM堆空間的變化。我們仔細觀察一下在14:42:05~14:42:25之間曲線變化,你會發現使用堆的數量,突然間急劇下滑!這代表這一點,當一個線程拋出OOM異常后,它所占據的內存資源會全部被釋放掉,從而不會影響其他線程的運行!
講到這里大家應該懂了,此題的答案為一個線程溢出后,進程里的其他線程還能照常運行。注意了,這個例子我只演示了堆溢出的情況。如果是棧溢出,結論也是一樣的,大家可自行通過代碼測試。
總結:其實發生OOM的線程一般情況下會死亡,也就是會被終結掉,該線程持有的對象占用的heap都會被gc了,釋放內存。因為發生OOM之前要進行gc,就算其他線程能夠正常工作,也會因為頻繁gc產生較大的影響。
一、問題來源
一次生產事故,由於一次性從數據庫查詢過多數據導致***線程*** OOM:Java heap space 異常(千萬級表,JVM堆內存2G),但是在線程OOM發生時,java進程卻沒有立即掛掉。
不符合所謂發生OOM,程序就會掛的“預期”,因此進行深入了解。
二、OOM與異常
說到底OutOfMemoryError也只是一個java中的異常而已,屬於Error一系非檢查異常:
Object
Throwable
Error
VirtualMachineError
OutOfMemoryError
堆內存不夠與異常的關系
線程發生OOM Java heap space,首先是堆空間不夠了,然后再由jvm在申請分配空間的方法調用上拋出OOM異常。
對於線程,它會像處理普通異常一樣,處理OutOfMemoryError。
三、異常與線程
線程是資源調度的基本單位,Java在設計線程時充分考慮了線程的獨立性。在異常方面,保持了線程異常的獨立性,在線程執行中發生的異常,都由線程自身解決,不會拋出到執行它的線程。
在線程的實現上,也保證了這種獨立性。
檢查異常不可拋
線程的實現java.lang.Runnable實現了java.lang.Runnable接口,線程通過其run方法運行,方法簽名如下:
public abstract void run();
由java語法保證了實現Runnable接口或者繼承Thread類的子類,其run方法也不能聲明拋出任何檢查異常(checked exception)。因此在線程方法執行中發生的任何檢查異常,必須在線程中處理。
默認異常處理器
除了檢查異常,java中還有非檢查異常(unchecked exception),這種異常無需顯式聲明也能沿着方法調用鏈向上拋出。線程對於這種未處理的異常,提供了默認異常處理器:
/** * Dispatch an uncaught exception to the handler. This method is * intended to be called only by the JVM. (將未被捕獲的異常分發給處理器。這個方法只被JVM調用) */ private void dispatchUncaughtException(Throwable e) { getUncaughtExceptionHandler().uncaughtException(this, e); }
Thread的init()
方法線程至少有一個默認異常處理器,兜底的異常處理器是當前線程父線程的線程組ThreadGroup
,可以看到線程組是有能力處理異常的:
public class ThreadGroup implements Thread.UncaughtExceptionHandler {}
線程通過這兩種機制,保證內部發生的異常,在線程內解決,而不會拋出給啟動線程的外部線程。
四、JVM退出條件
java虛擬機退出的條件是:虛擬機內不存在非守護線程。
線程發生未處理的異常(未處理異常由默認異常處理器處理)會導致線程結束,而與JVM的退出毫無關系。
OOM也是一種異常,它的發生也不會導致JVM退出。以下實例說明:
static class OOMObject { } // 為快速發生oom,設置堆大小; VM args: -Xms20m -Xmx20m public static void main(String[] args) throws InterruptedException { new Thread(() -> { List<OOMObject> list = new ArrayList<>(); while (true) { list.add(new OOMObject()); } }).start(); while (true) { System.out.println(Thread.currentThread().getName() + " continuing..."); Thread.sleep(1000L); } }
線程拋出java.lang.OutOfMemoryError: Java heap space后,main線程依舊會循環打印main continuing...。
線程中發生OOM異常如此,發生其他異常也如此,不影響其他線程,也不會導致JVM退出。
五、OOM與JVM退出
OOM的發生表示了此刻JVM堆內存告罄,不能分配出更多的資源,或者gc回收效率不可觀。一個線程的OOM,在一定程度的並發下,若此時其他線程也需要申請堆內存,那么其他線程也會因為申請不到內存而OOM,甚至連鎖反應導致整個JVM的退出。
以上示例沒有導致JVM退出的原因在於,線程通過往局部變量集合中不斷加入對象,產生OOM。線程因異常退出后,集合中的對象由於引用不可達,會被gc,這樣就有了足夠的堆內存供其他線程使用。
若示例中的list是一個“全局”的類static變量,那么即使線程退出,內存也得不到釋放。這時其他線程如果不斷再申請堆內存資源,就會造成連鎖反應導致JVM退出。