处理缓慢的资源泄漏

使用Java监视器查找资源泄漏

查找缓慢的资源泄漏是使应用程序服务器长时间保持正常运行的关键。 在这里，我解释了如何使用Java监视器来发现缓慢的资源泄漏，以及如何验证它们是实际的泄漏，而不仅仅是额外的预分配到某些HTTP连接器或数据库池中。 如果执行这些步骤，则可以摆脱定期重新启动，并真正开始依赖服务器。

缓慢的资源泄漏是一个问题，因为它们迫使您定期重新启动应用程序服务器。 反过来，这意味着您始终必须密切注意服务器，因为它们随时可能崩溃。 最终，您不能依赖遭受缓慢资源泄漏的服务器。 跟踪和解决缓慢的资源泄漏需要时间和耐心。 一旦完成几次，这并不是很难做到的。

您还需要一个监视工具，该工具可以显示过去几周甚至几个月内来自服务器的统计信息。 如果在服务器上启用了更长的数据存储，则可以使用Java监视器来执行此操作。 要在Java监视器中启用此功能，请首先开始对服务器使用Java监视器 。 在带有服务器图形的页面上，可以通过切换到“ 1周”或“ 1个月”视图来启用更长的数据，如下所示。

第一步是查看过去一周中服务器的数据。 为了发现资源泄漏，我发现绘制一周的数据比查看Java监视器标准的两天的数据要好。 峰平滑了，这些图让我看看例如内存使用随时间如何发展。

为了预测即将发生的中断和缓慢的资源泄漏，我寻找两种模式。 首先要检查的模式是，资源使用量不会随时间增加，而会随着每日流量的增加和减少而增加和减少。 当一天的流量减少后，我预计资源使用量将回落到名义水平。 我检查资源使用率是否每次都回落到同一水平。

请注意，我故意使用模糊的术语，例如“资源”。 在实践中，我查看所有内存，文件描述符以及HTTP连接器和数据库连接池的图形。 所有这些都是缓慢的资源泄漏的候选者。

当我看到资源似乎在增长的时候，我切换到数据的每月视图，甚至年度视图。 这将压缩图中的数据，并使缓慢的资源泄漏更容易发现。

这是资源使用情况可疑更改的示例。 在这种情况下，系统上的垃圾收集器突然变得更加活跃。 此时，系统或系统负载没有变化。

我要注意的第二种模式是服务器重启重启后资源分配急剧下降。 重新启动应用程序服务器时，如果资源使用量显着下降，则可能表明资源泄漏缓慢。 重新启动之后，通常会像重新启动之前那样降低资源使用量，因为所有池和缓存都开始为空。

这是一个与重启相关的资源使用变化的示例，该变化并不表示有问题。 重新启动后一段时间（甚至几天），资源使用情况已更改，但随后又恢复到正常水平并停留在该水平。

这是另一个。 甚至更加可疑，因为重新启动后资源使用率并未恢复。 它只是掉下来并停留下来。 这几乎肯定是一个问题。

一旦确定资源使用模式可疑，就必须确认这实际上是一个缓慢的泄漏。 很有可能是缓存或池中填充了更多缓存，从而随着时间的推移提高了资源使用率，而没有实际的泄漏。 在这一步中，我将遍历线程和数据库池的图以及HTTP会话的图。 我试图从那里的图表来解释提高的资源使用情况。

例如，在这里我们看到JVM中活动的线程，但线程数量有些奇怪的下降。 这些下降表明系统重新启动。

但是，如果将该图与同一台服务器上的HTTP连接器池图进行比较，我会发现HTTP连接器池中预分配的线程数同样会上下波动。

这可能意味着没有缓慢的资源泄漏。 最有可能的是，池中的额外线程保持状态，从而导致其他资源也增加。 我可能会记下具体注意此服务器的信息，但我还没有开始深入研究资源泄漏。

只有当我无法解释池中分配的额外资源和活动HTTP会话的数量时，我才真正开始挖掘。 如下所述： 如何找到资源泄漏缓慢的根本原因 。

解决缓慢的资源泄漏

我们研究了如何较早发现缓慢的内存泄漏。 在那里，我们看到了如何找到缓慢的资源泄漏，以及如何将其与预期的池增长行为区分开。

在这里，我想解释一下如何确定缓慢的资源泄漏的根本原因，以及最终如何解决它们。 修复缓慢的资源泄漏几乎总是需要更改代码，因此，如果您无法更改代码，则无法修复缓慢的资源泄漏。 在这种情况下，您将必须找到可以的人。

确定缓慢的资源泄漏的根本原因的过程类似于发现快速泄漏的过程。 主要的区别是时间对您不利。 对于快速泄漏，您可以轻松地进行几次迭代，而缓慢的泄漏则可能需要数周或数月的时间才能显现出来。 迭代可能是一年的四分之一。 为了加快泄漏速度，您可以快速更改代码并“实时查看其运行状况”。 对于较慢的泄漏，这仅意味着您将永远找不到真正的问题。

要遵循的步骤是：

1. 识别泄漏的资源（完成，是的！）
2. 收集有关该资源的证据
3. 撰写有关问题所在的论文，看看证据是否支持您
4. 向您认识的人展示您的分析结果，从而将您的证据撕成碎片
5. 设计并实施修复

请注意，我们通常通常只快速地执行步骤3，然后将所有精力花在步骤5上，却发现真正的问题是其他问题。 我应该知道，因为我犯错的次数比我愿意承认的还要多。

一旦知道泄漏了哪些资源（例如内存，文件描述符，CPU周期，线程），便开始收集有关泄漏的证据。 该证据来自多个来源。 如果泄漏的资源仅在您的代码中很少使用，则应用程序源代码是开始收集的好地方。 如果这是在各处（例如内存）使用的东西，那么查看源代码通常很耗时，并且效率不高。 因此，这是我要寻找证据的备忘单：

• 记忆
  --->堆转储
• 文件描述符
  ---> Java监视器的线程池图以及lsof或sockstat
• 中央处理器
  --->线程转储
• 线程数
  ---> Java监视器的线程池图和线程转储
• 数据库连接
  --->在JDBC驱动程序上启用资源泄漏检测

收集证据时，保持开放的态度非常重要。 得出关于正在发生的事情的结论是非常诱人的。 相反，只需查看很酷的证据并消除可能的问题。

至关重要的一步是向不惧怕挑战您的人提供您的证据和思路。 此步骤是为了防止您在分析中犯错误，并且必须等待几周才能发现自己是错误的。 在这个阶段，只是点头和鼓掌的人可能弊大于利，不管这个人的意图多么好。 找到合适的人，并告诉该人您需要严格的审查。

一旦分析克服了这一挑战，您就可以最终开始考虑解决方案。 该解决方案需要包括两个部分：1）它需要以使系统为您提供有关刚刚发现的问题的证据的方式来改进日志记录和监视，以及2）它需要实际解决该问题。

如果您的解决方案不正确，改进的日志记录将为您提供新的新证据，以供您进行第二次（可能是最终的！）迭代。

参考：在Java-Monitor博客上，我们的JCG合作伙伴 Kees Jan Koster处理缓慢的资源泄漏。

翻译自: https://www.javacodegeeks.com/2013/09/dealing-with-slow-resource-leaks.html