工程门户网站建设,百度搜索技巧,建网站服务器用哪种,网站及app开发一周前#xff0c;我被要求修复一个有内存泄漏问题的webapp。 考虑到过去两年左右的时间里我已经看到并修复了数百个泄漏#xff0c;我想这有多难。 但是事实证明这是一个挑战。 12小时后#xff0c;我发现该应用程序中不少于5个漏洞#xff0c;并设法修复了其中4个漏洞。… 一周前我被要求修复一个有内存泄漏问题的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很快就解决了。 我的第五个也是最后一个问题就是这样。 我仍然因为OutOfMemoryErrorPermGen而使应用程序崩溃。 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博客 的案例研究 。 翻译自: https://www.javacodegeeks.com/2013/03/hunting-down-memory-leaks-a-case-study.html
