在這個站點和其他地方，傳統的智慧是不要捕獲java.lang.OutOfMemoryError，除非是為了清理，而只是讓 JVM 崩潰并重新啟動。給出的原因是它可能使行程處于無效狀態。好吧，這似乎是一個很好的理由。
但是……這不是專屬的OutOfMemoryError。如果處理不當，任何例外都可能留下無效狀態。為什么這被認為是可以的：
String handleRequest(String name) {
try {
if (name.equals("buggy")) return buggy();
else if (name.equals("hungry")) return hungry();
else throw new IllegalArgumentException();
} catch (Exception e) { // <-- not catching OutOfMemoryError
return "Error: " e;
}
}
String buggy() {
bunnyLock.lock();
// oops! can throw ArrayIndexOutOfBoundsException due to using round instead of floor
var res = bunnies[(int) Math.round(Math.random() * bunnies.length)];
bunnyLock.unlock();
return res;
}
String hungry() {
var b = new byte[2_000_000_000]; // 2 GB because why not
...
}
但是把catch改為Throwable不是嗎？ArrayIndexOutOfBoundsException不知何故，它被認為更安全，但是這種buggy方法會使狀態無效，而分配失敗hungry是沒有問題的。
你可能會說，好吧，你應該修復buggy永遠不要讓狀態無效：
String buggy() {
bunnyLock.lock();
try {
// oops! can throw ArrayIndexOutOfBoundsException due to using round instead of floor
return bunnies[(int) Math.round(Math.random() * bunnies.length)];
} finally {
bunnyLock.unlock();
}
}
我同意。事實上，我非常同意，以至于我認為任何地方的每一段代碼都應該像這樣是例外安全的。然后你可以安全地假設即使是一個OutOfMemoryError也沒有留下任何無效的狀態。
那么，我是否遺漏了什么并且OutOfMemoryError真的更危險？
uj5u.com熱心網友回復：
但是......這不是 OutOfMemoryError 獨有的。如果處理不當，任何例外都可能留下無效狀態。
不同的定義。
正常例外（即除了 InternalError 和 OOME 之外的所有例外）具有明確定義的行為：代碼（通過執行陳述句throw someException;）或 JVM 本身（例如通過執行foo.instanceMethodwhere fooresolves to null，導致 JVM 拋出 NPE）拋出例外. 這意味著在拋出例外時，該背景關系的執行停止并且執行跳轉到相關的 catch 塊，或者如果沒有，則該方法被中止并且呼叫者現在拋出這個例外，依此類推。
除非您不擅長編程，否則這不會導致無效狀態。不幸的是，大量的 SO 答案和教程在編程方面很糟糕，他們這樣做：
try {
some code here;
} catch (IOException e) {
e.printStackTrace();
}
...這使代碼處于無效狀態：問題是，在該 catch 塊之后繼續執行，這很糟糕。撰寫不想關心某些例外的代碼的正確方法是：
try {
some code here;
} catch (IOException e) {
throw new RuntimeException("unhandled", e);
}
e.printStackTrace()與完全損壞的版本相比，這只是丑陋的。更新 IDE 的模板！
無論如何，這就是“未定義的行為”的意思——糟糕的代碼。你可以對任何代碼這么說：好吧，那個代碼可能有錯誤，那么，它有什么作用？沒人知道！- 是的，好吧，但是把這個論點帶到它的邏輯結論，你唯一剩下的選擇就是把你的電腦扔出窗外，和阿米什人一起生活。
幸運的是，java.*類和所有撰寫良好的庫（在這個意義上最常用的庫都撰寫得很好）不會執行上述操作 - 如果它們拋出東西，則行為不是“未定義的”。一般來說，所有操作都是原子的：要么它作業，要么它完全什么也沒做，而是拋出了一個例外（與上面的糟糕代碼相比，它的作用就像它作業一樣，因為該方法正常回傳，但是你的堆疊上有一個堆疊跟蹤控制臺和方法沒有做它的javadoc說它應該做的事情）。
當社區說 OOME 導致未定義的行為時，他們的具體含義是 OOME 是一種特殊的雪花，在這方面：
OOME 可以“在”其他受保護的執行背景關系中發生：與幾乎任何其他例外不同，它可以被拋出到不期望處理例外的 JVM 內部，因此，它會留下例如檔案句柄半打開和處于未定義的脆弱狀態（與該句柄互動會導致奇怪的例外或更糟，未定義的行為），等等。
這就是區別。如果，比如說，寫一個OutputStream你從那里得到的東西Files.newOutputStream會導致一些 IOException，那么行為仍然是明確定義的。這張唱片沒有任何變化。通常，給定：
try (var out = Files.newOutputStream(.. path ..)) {
out.write(5);
out.write(11);
}
在.write(5)命令中，正常回傳的 [A] 在此時您知道“5”至少在作業系統的核心檔案快取中（不再在您的 JVM 的檔案快取中），或者 [B] 它拋出 IOException這將準確地代表手頭的問題。
假設.write(5)拋出了一些例外，你抓住了它，然后你想繼續.write(11)排隊。什么都沒有改變：你仍然有相同的設定：任何一個都可以作業（假設例外是：你沒有寫訪問權限，并且在你提示用戶修復它并讓執行緒休眠一段時間的情況下，用戶實際上sudo chmod修復了它，然后取決于作業系統和 java 的作業方式，這可能意味著未來的.write呼叫現在可以正常作業！） - 或者很可能不會，但你仍然會得到“如預期”的例外：正確描述的 IOExceptions問題。
與 OOME 相比：如果.write(5)拋出 OOM，那么.write(11)據您所知，可能會導致您的計算機從揚聲器中播放貝多芬的《歡樂頌》 - 系統處于不穩定狀態，并且您擁有的 OutputStream 現在可能以 javadoc 的方式運行不包括。
請注意，這不是通用的。并非所有 OOME 都會導致“不穩定”系統。例如，這段代碼非常好：
byte[] bigArray;
try {
bigArray = new byte[100000000];
} catch (OutOfMemoryError e) {
// handle the fact that you can't make em that big
}
本質上，如果任何方法呼叫拋出 OOME，您需要接受現在各種事物可能處于 javadoc 未描述的狀態，并且其行為取決于各種奇怪的因素（作業系統、JVM 供應商、Java 版本、月亮...），但一些原語，主要是new arr[size]操作，你知道發生了什么并且可以可靠地回應OOME。
uj5u.com熱心網友回復：
OOME 的問題不在于分配大記憶體塊可能會失敗，而是此類分配分配了所有可用的東西。然后任何其他執行緒中的任何其他分配都將失敗。
并且需要考慮在編碼時任何分配都可能失敗，這從經濟角度來看是不切實際的。您放棄了 java 和/或您的技術堆疊和業務抽象提供的許多高級功能，并且需要在比處理檔案 io 的位置更多的位置處理底層記憶體資源。
所以我同意可以有完全能夠處理 OOME 的程式。只是從經濟角度來看，它們并不實用。
另一個原因是，將 jvm 保持在如此高的記憶體使用水平會經常啟動垃圾收集，因此 cpu 基本上只忙于做 gc 作業。從經濟角度來看，也使其無用。
uj5u.com熱心網友回復：
假設我們的整個專案都是完美的代碼，0 bug，即可能只遇到來自系統資源和用戶輸入的例外，并且在發生此類例外時始終保持狀態有效，其中一個區別是代碼如下：
bunnyLock.lock();
try {
doBunnyThings();
} finally {
bunnyLock.unlock(); // assume that this requires memory, e.g. because it's a custom logging implementation of Lock
}
...假設該finally塊的代碼僅包含從不拋出的“安全”代碼。如果它是因為ArrayIndexOutOfBoundsExceptioninside被呼叫的doBunnyThings，那是一個非常安全的假設。但是，如果 OOM 由 引發，則該塊也doBunnyThings失敗的可能性更高，因為記憶體仍然很低。然后違反假設并且所有賭注都關閉，因此不應捕獲由此產生的OOM。finally
也就是說，我不太相信。例如，后面的日志記錄bunnyLock.unlock()也可能因為磁盤空間不足而失敗，a IOException，但這不被認為是世界末日。并且遵循完美的代碼指南，bunnyLock.unlock()應該讓鎖保持解鎖狀態，即使它的日志記錄由于 OOM 而失敗。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/489147.html