Java Spring：在 OutOfMemoryError 之后重新运行死线程答案

【问题标题】：Java Spring: ReRun died thread after OutOfMemoryErrorJava Spring：在 OutOfMemoryError 之后重新运行死线程
【发布时间】：2012-02-11 18:58:39
【问题描述】：

我用 Spring 开发了一个应用程序。我有一个 bean 来创建一个线程，但是在这个线程的执行过程中，在运行时，JVM 会抛出 OutOfMemoryError - Java Heap Space。
我要问的是以下解决方案是否适合解决问题：一旦抛出线程死亡并释放线程先前占用的内存，然后我通过另一个线程（我称之为 RestartThread），我意识到线程已经死亡（没有捕获错误），然后：
1) 调用垃圾收集器，有效释放死线程的内存；
2) 调用死线程的run()函数，重新启动死线程的前一个实例（包括死线程使用的私有变量，即使在产生'OutOfMemoryError'后仍保留在内存中）。

您如何看待这件事，它可能会产生问题？重新启动先前死亡线程的正确解决方案是否正确？

在此先感谢，
--Alucard

【问题讨论】：

您可能应该找出内存不足的原因（例如泄漏引用或您的应用程序需要的内存比您给它的更多）并尝试修复它，而不是尝试恢复来自OOM（这可能是最困难的）
你不应该依赖这个。见stackoverflow.com/questions/3058198/… 和stackoverflow.com/questions/2679330/…

标签： java multithreading spring out-of-memory restart

【解决方案1】：

从OutOfMemoryError 中恢复非常困难，尤其是在多线程环境中，甚至通常是不可能的。您可能应该找出内存不足的原因（例如泄漏引用或您的应用程序需要的内存比您给它的更多）并尝试修复它，而不是尝试从中恢复。

即使您可以让抛出错误的线程死亡并重新启动它，重新启动的线程也可能会在开始时再次死亡。在更糟糕的情况下，根本原因可能在程序的其他部分。这意味着您的应用程序中的其他线程将开始抛出相同的错误，因为它们会尝试分配新对象，从而导致错误在您的应用程序中级联，最终整个事情会严重崩溃。

内存不是您唯一的问题。如果被 OOME 终止的线程正在处理中并触及其他线程也使用的某些共享对象的状态，那么您的应用程序状态几乎可以是任何东西（即不一致）。此外，如果另一个线程正在等待某个已终止线程所持有的监视器（互斥锁）或类似的（等待/通知等），则另一个线程可能会陷入死锁。在大多数情况下，编写恢复逻辑并检查恢复是否成功将非常困难，因为在您确定应用程序已真正恢复之前，需要检查的变量和事情太多了。

【讨论】：

感谢您的回复。我认为，如果我同意终止线程而不在内部调用 OutOfMemoryError，那么之前由 run() 中的对象分配的内存被释放，那么可能值得考虑重新启动线程，但需要重新调用函数运行（）。您对此有何看法
内存不是你唯一的问题。如果被 OOME 终止的线程正在处理中并触及其他线程也使用的某些共享对象的状态，那么您的应用程序状态几乎可以是任何东西（即不一致）。此外，如果另一个线程正在等待某个已终止线程所持有的监视器（互斥锁）或类似情况，则另一个线程可能会陷入死锁。在大多数情况下，编写恢复逻辑和检查将非常困难，因为在您确定应用程序已经真正恢复之前，有太多的变量和事情需要检查
好的，我明白了。非常感谢您的澄清

【解决方案2】：

尽一切努力阻止OutOfMemoryError。当 JVM 没有任何其他选择时，它会抛出它，即所有可以被 GC 删除的对象都已被删除。当这种情况发生时，JVM 通常甚至没有资源来优雅地终止。它应该被杀死并重新开始。大多数情况下，即使您尝试捕获OutOfMemoryError 并取消链接某些资源，这也将无法正常工作，并且至少无法正常工作。

【讨论】：

【解决方案3】：

您可以尝试通过生成 Heap Dump 来了解为什么会出现 OOM 错误见这里：

Link

虽然这里的答案是针对 JBoss Application Server，但它应该适用于任何 java 进程的一般情况。

稍后你可以分析这个转储，也许你会发现生成了很多相同类型的对象。

希望对你有帮助

【讨论】：

感谢您的建议，非常有用。问题是我试图不向JVM传递更多参数，所以我试图从外部解决问题。
我认为这个选项是一种临时检查，可以帮助您解决问题的根本原因。诸如“重新启动”之类的方法只是一种解决方法，它们不能解决问题，而只能帮助恢复...
这是真的。感谢回复