JVM是否可以从OutOfMemoryError中恢复而无需重新启动

它可能有效，但是通常是一个坏主意。无法保证您的应用程序将成功恢复，或者无法知道它是否成功。例如：即使采取恢复步骤（例如释放保留的内存块）后，实际上可能没有足够的内存来执行请求的任务。在这种情况下，您的应用程序可能陷入一个循环，在该循环中，它似乎反复出现恢复，然后再次耗尽内存。OOME可以在任何线程上抛出。如果应用程序线程或库未设计为应对该问题，则可能会使某些长期存在的数据结构处于不完整或不一致的状态。如果线程由于OOME而死，则作为OOME恢复的一部分，应用程序可能需要重新启动它们。至少，这会使应用程序更加复杂。假设一个线程使用通知/等待或更高级别的机制与其他线程同步。如果该线程从OOME中消失，则可能会留下其他线程来等待通知（etc），这些通知永远不会出现...例如。为此进行设计可能会使应用程序更加复杂。总而言之，设计，实施和测试要从OOME中恢复的应用程序可能会很困难，尤其是在应用程序（或其运行所在的框架或所使用的任何库）是多线程的情况下。将OOME视为致命错误是一个更好的主意。另请参阅我对相关问题的回答：编辑 -针对此后续问题：换句话说，如果将OOME抛出到应用程序服务器（jboss / websphere / ..）中，我是否必须重新启动它？不，你不必须重新启动。但这可能是明智的选择，尤其是如果您没有良好/自动的方法来检查服务是否正常运行时。JVM将恢复正常。但是，应用程序服务器和应用程序本身可能会恢复，也可能无法恢复，这取决于它们为应对这种情况而设计的程度。（我的经验是，某些应用程序服务器并非旨在解决此问题，并且设计和实施复杂的应用程序以从OOME中恢复非常困难，而正确地对其进行测试则更加困难。）编辑2针对此评论：“其他线程可能会等待通知（等）永远不会到来”真的吗？被杀死的线程是否不会解开其堆栈，随即释放资源，包括持有的锁？对真的！考虑一下：线程＃1运行此命令：    synchronized(lock) {         while (!someCondition) {             lock.wait();         }    }    // ...线程＃2运行此命令：    synchronized(lock) {         // do stuff         lock.notify();    }如果线程＃1正在等待通知，并且线程＃2在该// do something节中获得OOME ，则线程＃2将不会进行notify()调用，线程＃1可能会永远卡住，等待永远不会发生的通知。当然，保证线程＃2释放lock对象上的互斥体...但这还不够！如果不是，线程运行的代码不是异常安全的，这是一个更普遍的问题。我听说过“异常安全”这个词（尽管我知道您的意思）。Java程序通常没有设计为可应对意外异常。确实，在上述情况下，使应用程序异常安全可能很困难，甚至不可能。您需要某种机制将线程＃1的故障（由于OOME）变成对线程＃2的线程间通信失败通知。Erlang可以做到这一点……但是Java却没有。他们之所以能够在Erlang中做到这一点，是因为Erlang进程使用严格的类似于CSP的原语进行通信。即没有共享的数据结构！

JVM是否可以从OutOfMemoryError中恢复而无需重新启动

3回答