java - 调试奇怪的内存泄漏 - Java/Tomcat

Question

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

我们尝试在 1 周的冲刺中从新生成的新产品更新生产代码，该应用程序已经运行了几个月没有打嗝，然后这段新代码使我们的 Linux 服务器在一段时间后开始交换。

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

所以，似乎是从某处泄漏了内存，似乎是从新代码中泄漏的，但奇怪的是它不在 JVM 内部，关于如何调试它有什么想法吗？

谢谢!

Answer 1

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

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

1. 估计您的程序应该使用的内存中值和峰值。您必须能够解释与这些指标的所有偏差。如果不能，请继续执行步骤 3。

2. 假设您正确执行了第 1 步并且能够解释所有偏差，您就可以排除泄漏(对于如此含糊的建议感到抱歉，但调试与侦探一样好)。您现在应该专注于 GC 调优。首先，启用 GC 日志记录。查看您的堆是否真的已满，以及 GC 将大部分时间用于收集的位置。 This可能是开始优化的一个很好的起点。尝试查看调整 GC 选项是否有帮助。尝试使用收集算法、最大/最小堆大小、生成比率等进行试验。只有在排除泄漏后才进行试验(步骤 1)。

3. 假设您正确执行了第 1 步并且无法解释所有偏差，您可以假设某处存在漏洞。使用内存分析器查看哪些对象对堆大小增长贡献最大。让探查器长时间运行——让你的程序处理一些它通常期望得到的请求，然后让它相对隔离。如果内存级别持续增长，则可能某处发生泄漏。如果不是，则可能不是内存泄漏。你能指出你程序中可能创建它们的部分吗？如果是，请尝试发送几个只针对程序的那部分的请求。它是否确定性地复制了问题？如果不是，请重复第 3 步。如果是，请使用分而治之并重新应用第 3 步，直到找到导致问题的类/方法。它也可以是多个部分的某种组合(这意味着它们单独看起来可能是无辜的，但它们在一起可能会形成一个辉煌的犯罪集团)。

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

祝您运动愉快!