调试一个奇怪的内存泄漏 - Java/Tomcat答案

【问题标题】：Debugging a strange memory leak - Java/Tomcat调试一个奇怪的内存泄漏 - Java/Tomcat
【发布时间】：2011-08-24 11:50:33
【问题描述】：

我在 Tomcat 下运行的 Java 应用程序遇到了一个非常奇怪的问题。

我们尝试在 1 周的 sprint 中从新生成的新代码更新生产代码，该应用程序已经运行了几个月而没有出现任何问题，然后这个新代码使我们的 Linux 服务器在一段时间后开始交换。

非常奇怪的是，当查看 VisualVM 的内存使用情况时，它从未超过最大堆大小，JVM 不会抛出 OutOfMemory，机器只是开始交换，即使在那之后 JVM 也会继续运行。

所以，似乎是从某个地方泄漏了内存，似乎是来自新代码，但奇怪的是它不在 JVM 内部，有什么调试方法的想法吗？

谢谢！

【问题讨论】：

可能有助于显示代码。
涉及的任何本机代码（通过 JNI 或 JNA），还是纯 Java？
可能是由于内存映射文件？ top 显示 java 进程的内存使用情况是什么？
可能其他东西开始在服务器上运行，占用了足够的 RAM 来强制 unix 开始交换
我无法显示一些代码，哈哈，有 400 多个类，从稳定代码到不稳定代码没有任何值得注意的变化，我真的很想知道一些方法来开始调试。

标签： java tomcat memory-leaks

【解决方案1】：

交换不是泄漏的决定性指标。它是由低物理内存造成的。在 Linux 上使用 vmstat 获取交换使用情况。尝试使用不同的机器，尝试配置 --swap 大小、物理内存大小、地址空间。

如果您确信问题出在您的程序中，请尝试以下操作：

估计您的程序应该使用的内存中值和峰值。您必须能够考虑与这些指标的所有偏差。如果不能，请继续执行第 3 步。
假设您正确执行了第 1 步并且能够解释所有偏差，您可以排除泄漏（对于此类含糊的建议感到抱歉，但调试仅与侦探一样好）。您现在应该专注于 GC 调优。首先，启用 GC 日志记录。看看你的堆是否真的满了，以及 GC 大部分时间都花在哪里收集。 This 可能是开始优化的一个很好的起点。尝试查看调整 GC 选项是否有帮助。尝试使用收集算法、最大/最小堆大小、生成比率等进行试验。仅在排除泄漏时进行试验（步骤 1）。
假设您正确执行了第 1 步并且无法解释所有偏差，您可以假设您在某处有泄漏。使用内存分析器查看哪些对象对堆大小增长的贡献最大。让分析器长时间运行——让你的程序处理一些它通常期望得到的请求，然后让它相对隔离。如果内存级别不断增长，您可能在某处发生泄漏。如果不是，那么它可能不是内存泄漏。你能指出你的程序中可能创建它们的部分吗？如果是，请尝试发送几个仅针对您程序的该部分的请求。它是否确定性地复制了问题？如果不是，请重复第 3 步。如果是，请使用分而治之并重新应用第 3 步，直到找到罪魁祸首的类/方法。它也可以是多个部分的某种组合（这意味着它们单独看起来可能很无辜，但它们一起可能会形成一个出色的犯罪集团）。

希望这有帮助，如果没有，请在我的帖子中发表评论。

祝你运动顺利！

【讨论】：

非常非常非常非常感谢您的逐步说明...这是我知道应该做的所有事情，但我需要不时提醒我这一点。上周的调试让我感到疲倦，并且没有心态开始这样的调试，我目前正在研究它是否真的是应用程序中的泄漏或操作系统中的其他地方。

【解决方案2】：

如果您不使用它，我建议您使用visual VM version 1.3.2 和所有插件。与早期版本相比有了很大的提升。

烫发空间会发生什么？

您使用的内存设置是什么？当然是最小值和最大值，但是 perm 空间大小呢？

【讨论】：

【解决方案3】：

我建议您考虑在不使用 jvisualvm 的情况下创建堆转储。对于基于 Unix 的 Oracle JVM，这通常通过使用 kill 向 JVM 发送信号 3 来完成。

详情请见http://www.startux.de/index.php/java/45-java-heap-dumpyvComment45

然后您可以查看模式是否发生变化。

如果您没有从中得到任何想法，那么这可能是因为您正在存储一个非常大的原始字符串（其中包含底层字符串数组）的子字符串，或者因为您持有操作系统资源比如打开的数据库连接等。

您检查过您的连接池看起来不错吗？

【讨论】：