JVM 如何因 OOM 異常而死機？

Question

我查看了很多地方，但找不到 JVM 因 OOM 而死的原因。 我不考慮操作系統殺手。 為了提供一些背景信息，我有一個 Java 應用程序正在運行，它開始用完 memory，我知道它可能會在 JVM 開始殺死線程后繼續存在。

但是，我已經看到它在第一次 OOM 后運行了 30 多分鍾，並且在這個無響應的 state 中繼續運行，它可能會或不會恢復。 但是，在復制相同的步驟以觸發 OOM 后，我也看到它在第一次 OOM 之后立即崩潰。 系統在 memory 方面很好，問題只是在 JVM 方面。 所以，我的問題是：

1. JVM 在 OOM 期間會發生什么情況，它可能會崩潰或永久保持在無響應的 state 中？
2. JVM 如何殺死線程？ 是隨機的嗎？

Answer 1

從技術上講， OutOfMemoryError是“另一個可拋出的”，因此它可能會也可能不會殺死它被拋出的線程，具體取決於該線程如何處理其異常。

例如，如果它在最低級別有一個catch (Error e)塊，那么它可以在仍然運行的同時“承受”很多問題。

因此，如果您的OutOfMemoryError僅在優雅地處理此類錯誤的線程中拋出，那么您的系統可以繼續正常工作。

但這也是OutOfMemoryError的 2 個不尋常的屬性發揮作用的地方：

1. 它基本上可以被扔到 memory 被分配的任何地方，而且它會被扔到哪里是不可預測的，以至於看起來很隨機。 它經常被扔在分配最多 memory 的地方，但這並不總是如此。
2. 由於錯誤條件的性質，它表示在嘗試處理異常時很可能再次遇到完全相同的錯誤（例如，您可能會在嘗試生成有關內存不足的日志消息時用完 memory）。 這種遞歸性質使得可靠地處理OOME變得異常困難。

所以tl;dr對您的問題的回答是：

1. “這取決於”您的線程如何處理異常
2. 線程將因未能處理初始異常或未能處理嘗試處理初始異常時發生的異常而被殺死。 哪個線程被擊中是如此不可預測，以至於看起來是隨機的。