java - 处理预期的 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。如果 third-party-lib 在那里导致 OoM-Error，它不会对 Web 应用程序产生影响。另一方面，这会导致额外的工作来将新流程与 Web 应用程序的分析部分同步。是否有人对此类系统有任何经验(尤其是在系统稳定性方面)？

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

2) 我很确定是第三方库导致了 OoM-Error。我已经用不同大小的不同文件单独测试了分析部分。导致 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 世界中常常不受欢迎。自己生成线程可能会导致容器管理资源的方式出现问题。确保问题不是您自己造成的，尝试在测试环境中独立加载已知会导致问题的文件(如果可以确定的话)。这将帮助您确定问题是第三方库还是设计库。