DeleteOnExitHook 上的内存泄漏答案

【问题标题】：Memory Leak on DeleteOnExitHookDeleteOnExitHook 上的内存泄漏
【发布时间】：2017-02-28 08:57:47
【问题描述】：

我有一个 24/7 运行的 Java 应用程序，它连接到 MySQL 服务器和 TimerTask（正在运行 Akka）。在运行一周或更短时间后，我遇到了 OutOfMemoryError，堆转储显示了一个包含超过 400 万个字符串的 LinkedHashMap，它们有一个 java.io.DeleteOnExitHook 的 GC 根，使用 800 MB 的堆。

所有字符串都类似于 /tmp/jar_cachexxxx.tmp

这个问题在两台运行 OpenJDK Runtime Environment (build 1.8.0_101-b13) 的机器上是一致的。 JDBC 驱动程序是 maven "mysql-connector-java" 版本 5.1.38 上提供的驱动程序，我使用的是连接池 BoneCP，版本 0.8.0。

有人知道这个泄漏吗？

更新 -- 2016 年 5 月 12 日

在我们为项目更改编译器后，问题已解决。我们注意到 eclipse jar creator 是唯一与 jar 缓存有任何关系的东西，所以在我们用 maven 编译项目后，内存泄漏就消失了。

【问题讨论】：

您能否提供更多信息，您是如何访问数据库和使用 Akka 的？你在打电话 Java.io.File.deleteOnExit() 吗？你看过多少个看起来像“/tmp/jar_cachexxxx.tmp”的字符串？这可能是一个红鲱鱼。即使有 1000 个这些字符串也不占 800MB。尝试寻找其他字符串。
您如何确定所有字符串看起来像“/tmp/jar_cachexxxx.tmp”？ 800MB 意味着您需要大约 800MB/30bytes=26,666,666 个类似这样的字符串。

标签： java memory-leaks out-of-memory akka

【解决方案1】：

这是一个长期存在且众所周知的错误，多年来已多次向 Sun/Oracle 报告。当前的错误编号是JDK-4872014。

问题在于，每次您使用 delete-on-exit API 时，文件都会存储到 HashMap 中。由于在长时间运行的服务器中，您的代码很少会故意退出，因此如果您使用大量临时文件执行此操作，则地图可能会无限增长。

本质上，该 API 不适用于长时间运行的服务器，因为它并不是真正打算以这种方式使用的。如果您需要此功能，您需要自己实现它并按计划运行清理，并通过某种方式知道可以删除哪些文件。

【讨论】：

这不应该是JVM的错误。 JVM 需要记住应用程序退出时需要删除的所有文件。我很惊讶这仍然是一个悬而未决的问题。
你可能是对的。该 API 不适用于理想情况下永远不会关闭的进程。

【解决方案2】：

只有当你使用 eclipse 导出器“Runnable JAR file”然后选择“Package required libraries into generated JAR”时才会发生这种情况。

然后会使用eclipse JAR-in-JAR classloader，它使用了一个URLClassloader，根据这个问题会产生内存泄漏： How long are resources used (file descriptor and memory) for Java temporary files (jar_cache####.tmp)?

【讨论】：

有趣，这解决了我的问题。我运行了一个使用这些设置创建的独立服务。现在我将我的依赖项打包在一个单独的目录中，不再发生内存泄漏。

【解决方案3】：

您的应用程序中的某些内容正在使用 File.deleteOnExit。但是由于您的应用程序永远不存在，Java 必须跟踪所有这些文件，因为它们需要在它最终退出时被删除（这永远不会发生）。我建议您使用调试器找出应用程序的哪个部分执行此操作，然后找到替代方法。

【讨论】：

【解决方案4】：

文件的路径名中还有一条线索：“/tmp/jar_cachexxxx.tmp”。

显然，这些文件是在 URLClassloader 下载远程 JAR 文件并加载它时创建的。如果你有数百万个这样的字符串，这意味着你这样做太频繁了。

【讨论】：