Java JVM：内存分配失败后继续不安全？

我有一个进程，它使用一个库来执行一个耗时且消耗内存的步骤，有时会占用太多内存，并在一个大请求上引发分配失败。在这种情况下，接受失败并继续处理是合理的，因此我的解决方案是将对该工具的引用设为null，并创建一个新的引用，以便在后续输入上继续处理

我小组中的其他人对此策略提出质疑，他们说，一旦JVM内存变得非常紧张，以至于分配失败，JVM就会处于可疑状态：没有真正的证据，只有FUD。另一方面，我只能归纳地说我还没有看到不良影响（我还没有看到任何黑天鹅）

---

问：继续使用引发内存分配失败的JVM是绝对不安全的吗？

当内存不足时，其他线程也可能会内存不足，它们可能无法很好地处理这一问题。您可能会发现大部分时间都可以继续，但最好不要首先耗尽内存。

不，这不是绝对不安全的。不过，如果可以的话，避免这种情况显然要好得多，因为谁知道在分配内存失败后，数据结构将处于何种不确定状态

有许多应用程序（尤其是webapps）能够很好地经受内存分配失败的考验。然而，它是否安全在很大程度上取决于应用程序。不断更新共享资源的代码的性能会比Web应用程序的性能下降得更糟，再次举个例子，Web应用程序在不同的任务之间有很大程度的分离，而共享资源通常很少

---

最重要的是，您要仔细评估您的应用程序，并对可能遇到的陷阱有一个很好的了解。然后尝试在失败后尽快重新启动JVM。；）

我无法避免它，因为库是第三方的，我无法修改它。相关的数据结构都在这个库中，通过删除解析器（库中的东西）并创建一个新的解析器，我实际上是在重新设置应用程序的这一部分。我的问题，也许值得编辑来澄清，是关于JVM本身在这样一个事件之后的持续生存能力。这就是为什么它会吐出臭味而不是停下来。它相信自己能够继续开卡车。但当然，数据结构可能处于不确定状态。这就是为什么它会成为一个基于对你的应用程序仔细评估的价值判断。这是我的想法。一些有助于在学术环境中对抗FUD的参考资料会有所帮助。谢谢。对不起……我没有任何可以立即转告的文件。你可以随便看看JLS。有趣的是，如果一个赋值需要自动取消装箱，并且没有剩余空间，那么即使是赋值也会导致OOME。