处理预期的 java.lang.OutOfMemoryError: Java heap space 的解决方法

Question

我正在开发基于 Java 6/Tomcat 6.0 的 Java Web 应用程序。这是一个基于网络的文档管理系统。客户可以将任何类型的文件上传到该 Web 应用程序。上传文件后，会生成一个新线程，在其中分析上传的文件。分析是使用第三方库完成的。

这个第三方库在大约 90% 的分析作业中运行良好，但有时（取决于上传的文件）逻辑开始使用所有剩余内存，导致 OutOfMemoryError。

由于整个应用程序在单个 JVM 中运行，OoM-Error 不仅会影响分析作业，还会影响其他功能。在最坏的情况下，应用程序完全崩溃或保持不一致的状态。

我现在正在寻找一种相当快速（但安全）的方法来处理这些 OoM 错误。目前更换库是没有选择的（这就是为什么我没有提到库的名称，也没有提到做过什么样的分析）。有没有人知道可以做些什么来解决这个错误？

我一直在考虑启动一个新进程 (java.lang.ProcessBuilder) 来拥有一个新的 JVM。如果第三方库在那里导致 OoM-Error，它不会对 Web 应用程序产生影响。另一方面，这将导致将新流程与 Web 应用程序的分析部分同步的额外工作。有人对这样的系统有任何经验吗（尤其是在系统稳定性方面）？

更多信息： 1）分析部分可以概括为一种文本提取。该模块接收文件引用作为输入并将分析结果写入文本文件。生成的文本文件在 Web 应用程序业务逻辑中进一步处理。目前工作流是同步的。业务逻辑等待第三方库完成其工作。没有排队或其他异步方法。

2) 我很确定第三方库会导致 OoM 错误。我已经用不同大小的不同文件单独测试了分析部分。导致 OoM-Error 的文件非常小（大约 4MB）。我已经对该特定文件进行了进一步的测试。在拥有 256MB 堆的 JVM 时，分析由于 OoM 错误而崩溃。在具有 512MB 堆的 JVM 中通过相同的测试。但是，增加堆大小只会在短时间内有所帮助，因为更大的测试文件会再次导致测试由于 OoM-Error 而失败。

3) 上传文件的大小有限制；但当然每个文件不能有 4MB 的限制。操作系统和架构也是如此。系统必须同时在 32 位和 64 位系统（Windows 和 Linux）上工作

Answer 1

这取决于客户端和服务器以及网络应用程序的设计。您需要回答几个问题：

• 分析结果应该发生什么，应该什么时候发生？
• 客户端是否等待分析结果？
• 返回给客户的是什么？

您还需要确定 OOM 的性质。

您可能希望分别处理文件上传和文件分析。例如，您的 webapp 可以将文件上传到文件系统中的某个位置，您可以将分析部分推迟到 web 服务，该服务将传递对文件位置的引用。 Web 服务可能会或可能不会被异步调用，具体取决于上传文件的客户端在分析中出现问题时需要通知的方式和时间。

所有这些因素都会影响你的决定。

其他注意事项，您使用的是什么 JVM，操作系统是什么以及它在系统内存方面是如何配置的？是 JVM 32 位还是 64 位，上传时允许的最大文件大小是多少，您尝试过哪种垃圾收集器。

您可以从基础架构的角度解决此问题，而不是更改代码。限制文件上传的最大大小，从 32 位移动到 64 位，更改垃圾收集器，在确定其中一个库中是否存在错误或内存泄漏后升级库等。

另一个明显的危险信号，你说“产生了一个线程”。虽然这种事情是可能的，但在 JEE 世界中却常常不受欢迎。自己产生线程可能会导致容器管理资源的方式出现问题。确保您不是自己造成问题，在测试环境中独立尝试对已知会导致问题的文件加载文件（如果可以确定的话）。这将帮助您确定问题是第三方库还是设计库。

Answer 2

为什么不为每个第 3 方库提供一个（可能是集群的）应用程序来处理文件分析。这些应用程序是从您的主应用程序远程调用的（可能是异步的）。他们被传递了一个 URL，该 URL 指向他们应该分析的文件并返回他们的分析结果。

文件上传完成后，分析作业将被放入队列中。当分析应用程序崩溃后再次启动时，它将继续使用队列中的消息。