通过AppDynamics解决应用程序问题的速度提高了10倍–以最小的开销在代码级深度监视生产应用程序。 开始免费试用！

内存，内存，内存...

内存是Java的关键部分，尤其是内存管理。 作为开发人员，内存管理不是您要定期执行的操作，也不是您要手动执行的操作。 Java的一大优点是它能够为您处理内存模型。 当不使用对象时，Java会通过清理来帮助您。

但这也是问题开始的地方。 使用Java，也许您的应用程序不再使用对象，但是如果您不告诉虚拟机您不再使用它，则它不会清除它。 这是内存泄漏 。 我们都看过他们。 对象开始在您的堆中累积，您的应用程序停止运行。

内存泄漏通常是由于编程不当而导致的-通常是在开发人员未释放对对象的所有引用的情况下。 如您所知，Java中的类似对象被放到集合或映射中，因此如果您不从集合中删除特定的数据集，问题就会变得更加复杂。 收集的东西越多，您损失的空间就越大。

当Java为您管理内存模型，或者创建/销毁未使用的对象时，它将它们放入堆中。 该堆始终具有一定的大小，并具有最大可用空间。 如果内存管理不善，堆的空间将用完。 集合加起来，然后JVM崩溃。

诊断泄漏

传统上，有两种主要的内存泄漏诊断方法：堆转储和分析器。

第一个是堆转储，基本上可以让您查看哪个对象持有对集合的引用。 它可以使您对导致问题的对象有一个很好的了解，但它不会告诉您谁在访问集合，而谁没有访问集合。 它告诉您集合的位置，但不告诉您使用它的人的特征。 堆转储通常也非常大，以GB为单位，并且大堆转储很繁琐。 分析和打开堆转储，然后阅读并确定问题，需要大量资源。

第二种方法是堆转储和探查器的组合，可以使您更接近一点，但不多。 内存探查器会尝试帮助您分析堆转储。 他们拥有实时数据，现在您知道是谁在创建对象，但是您仍然没有真正导致泄漏的原因。

假设我有一个雇员对象。 员工对象被放入集合中，探查器将告诉您创建它的人。 探查器没有告诉您的是谁将其放入集合中以及从集合中将其删除。 探查器告诉您对象的诞生，而不是泄漏的原因。 无论如何，这可以帮助您缩小范围，但是您需要应用程序的扎实知识才能使探查器真正地帮助您确定原因，然后仍然需要大量时间和资源来查找泄漏。

我们从很多人那里听到了。 许多公司尝试使用这些工具，但是每隔几天他们的应用就会崩溃。 那他们怎么办？ 他们重新启动JVM或CLR。 他们的应用再次崩溃，然后重新启动。 应用程序管理是一场噩梦，因为他们无法找到或修复其内存泄漏。

堆转储和事件探查器都可以在开发和预生产中提供帮助，但是一旦您的应用大量使用，事件探查器就无法使用。 探查器会引入大量开销，堆转储几乎会停止生产中应用程序的所有处理。 基本上，您需要使该JVM / CLR上的应用程序脱机才能完成所有工作。

随着当今应用程序的发展，这些繁琐的过程变得越来越难维护。 随着应用程序变得越来越复杂，堆越来越大，最终，这些方法并没有减少它。

AppDynamics和内存泄漏

迄今为止，我们的方法一直是提供全面的事务快照，尤其是明显的代码问题，可以使您深入了解问题的根源。 为了有效地隔离和解决内存泄漏，事务和代码路径分析至关重要。

这带给我们AppDynamics的一些有趣的发展。 我们为公司提供了一种直接识别内存泄漏根本原因的方法。 您可以自动检测泄漏，确定是谁在创建泄漏，以及导致该泄漏的代码路径或业务交易。 您可以在此处了解更多信息。

这有好处吗？ 减少停机时间并降低MTTR。 我们很兴奋。 希望你也是。

通过AppDynamics解决应用程序问题的速度提高了10倍–以最小的开销在代码级深度监视生产应用程序。 开始免费试用！

翻译自: https://www.javacodegeeks.com/2016/10/apm-non-java-guru-leak.html