寻找内存泄漏：一个案例研究

一周前，我被要求修复一个有内存泄漏问题的webapp。考虑到过去两年左右的时间里我已经看到并修复了数百个泄漏，我想这有多难。

但是事实证明这是一个挑战。 12小时后，我发现该应用程序中不少于5个漏洞，并设法修复了其中4个漏洞。我认为这将是值得分享的经历。对于那些不耐烦的人–总而言之，我发现了

MySQL驱动程序启动后台线程
重新部署时未卸载java.sql.DriverManager
BoneCP从错误的类加载器加载资源
数据源已注册到JNDI树中，阻止了卸载
使用终结器的连接池与在单独线程中运行的Google的参考队列实现相关联

当前的应用程序是一个简单的Java Web应用程序，具有一些连接到关系数据库的数据源，中间是Spring以将内容粘合在一起，并将简单的JSP页面呈现给最终用户。没有魔术。还是我想。男孩，我错了。

第一站 -MySQL驱动程序。显然，最常见的MySQL驱动程序会在后台启动线程，以清理未使用和未关闭的连接。到目前为止，一切都很好。但是要注意的是，这个新创建的线程的上下文类加载器是您的Web应用程序类加载器。这意味着，在运行此线程并尝试取消部署webapp的同时，其类加载器被甩在了后面–加载了所有类。

显然，从2012年7月到2013年2月，发现此错误后，对其进行了修复。您可以按照MySQL问题跟踪器中的讨论进行操作。最终实现的解决方案是API的shutdown（）方法，开发人员在重新部署之前应该知道要调用该方法。好吧，我没有。我敢打赌，你们当中有99％的人也没有。

在典型的Java Web应用程序中，有一个适合此类关闭挂钩的好地方，即ServletContextListener类contextDestroyed（）方法。每次销毁servlet上下文时，都会调用此特定方法，例如，这种情况通常发生在重新部署期间。可能有相当多的开发人员意识到这个地方的存在，但是实际上有多少人意识到需要清理这个特定的钩子呢？

回到该应用程序，该应用程序还没有被修复。我的第二个发现还与上下文类加载器和数据源有关。使用com.jdbc.myslq.Driver时，它将自身注册为java.sql.DriverManager类中的驱动程序。同样，这是有良好意图的。毕竟，这是您的应用程序用来确定在连接到数据库URL时如何为每个查询选择正确的驱动程序的方法。但您可能会猜到一个问题：该DriverManager是在引导类加载器中加载的，而不是在Web应用程序的类加载器中加载的，因此在重新部署应用程序时无法将其卸载。

现在使事情真正变得奇怪的是，没有一般的方法可以自行注销驱动程序。对您尝试注销的类的引用似乎是故意向您隐藏的。在这种特殊情况下，我很幸运，应用程序中使用的连接池能够注销驱动程序。万一我记得问。回顾过去的类似案例，这是我第一次看到在连接池中实现这种功能。在此之前，我曾经必须枚举在DriverManager中注册的所有JDBC驱动程序，以找出应该注销的驱动程序。我无法向任何人推荐这种体验。

我想应该是这样。同一应用程序中的两次泄漏已经可以忍受一个以上。错误。泄漏报告中盯着我的第三个问题是sun.awt.AppContext及其静态字段mainAppContext。什么？我不知道该类应该做什么，但是我很确定手头的应用程序没有以任何方式使用AWT 。因此，我启动了一个调试器，以找出是谁加载了此类（以及为什么）。另一个惊喜：它是com.sun.jmx.trace.Trace.out（）。您能想到com.sun.jmx类将之称为sun.awt类的充分理由吗？我当然不能。但是，该类堆栈源自连接池BoneCP 。跳过导致该特定内存泄漏的代码行的绝对零方式。解？我的ServletContextListener.contextInitialized（）中的以下魔咒：

Thread.currentThread().setContextClassLoader(null); // Force the AppContext singleton to be created and initialized without holding reference to WebAppClassLoder sun.awt.AppContext.getAppContext();

但是我仍然没有做完：有些东西还在泄漏。 在这种情况下，我发现我们的应用程序将此数据源绑定到InitialContext（） JNDI树，这是一种很好的，标准化的方法，用于绑定对象以供将来发现。但是，再次强调–使用这种好东西时，您必须使用完全相同的contextDestroy（）方法从JNDI树中解除绑定此数据源来清理自己。

好吧，到目前为止，我们遇到了一些逻辑问题，尽管很少见并且有些晦涩难懂的问题，但是有了一些推理和google-fu很快就解决了。我的第五个也是最后一个问题就是这样。我仍然因为OutOfMemoryError：PermGen而使应用程序崩溃。 Plumbr和Eclipse MAT都向我报告说，罪魁祸首是把我的类加载器扣为人质的一个线程，名为com.google.common.base.internal.Finalizer。 “这家伙到底是谁？” –是黑暗吞没我之前我的最后一个想法。几个小时和四杯咖啡之后，我发现自己盯着三行：

emf.close(); 
emf = null; 
ds = null;

很难准确回忆一下在这段时间里发生的事情。我对WeakReferences ， ReferenceQueues ， Finalizers ， Reflection拥有远程记忆，而我第一次在野外看到PhantomReference 。即使到了今天，我仍然无法完全解释为什么连接池使用终结器以及将终结器绑定到在单独线程中运行的Google的参考队列实现的目的以及目的。

我也无法解释为什么关闭javax.persistence.EntityManagerFactory （在上面的代码中命名为emf并保存在应用程序自己的类之一中的静态引用中）的原因；因此，我不得不手动使该引用无效。以及对该工厂使用的数据源的类似静态引用。我确信Java的GC可以整天处理循环引用，但是，即使对于他来说，类，静态引用，对象，终结器和引用队列的神奇组合似乎也很难。因此，这是我漫长的职业生涯中的第一次，我不得不取消Java参考。

我是一个谦虚的人，因此不能说我在短短12个小时内能最有效地找到以上所有方法。但是我必须承认，过去三年来我几乎一直在处理内存泄漏。而且我什至拥有自己的创造力Plumbr来帮助我（实际上，其中五分之四的泄漏是Plumbr在30分钟左右的时间内发现的）。但是要真正解决这些泄漏，我花了一个多工作日的时间。

总体而言-在Java EE和/或类加载器世界中，显然有些问题。开发人员必须记住所有这些挂钩和配置技巧，这是不正常的，因为这根本不可能。毕竟，我们喜欢用头脑去做一些富有成效的事情。而且，从与两个流行的servlet容器（ Tomcat和Jetty ）捆绑在一起的变通办法可以看出，问题很严重。但是，解决该问题不仅需要缓解某些症状，还需要解决潜在的设计错误。

参考： 寻找内存泄漏：来自我们的JCG合作伙伴 Nikita Salnikov Tarnovski （来自Plumbr博客）的案例研究。