值得阅读的内存泄露分析总结和Tomcat调优
|
这个看名字就知道是用来检测是否存在内存泄漏的，后头看到Tomcat打点页面自带一个Find Leaks的成果，不知道是不是和这个有相关。然后我进这个类看了下就有了新发明，在这个类内里我看到GC日记内里执行system.gc的谁人类名!看下图： 这里这个gcDaemonProtection的参数在这个类的上面已经界说了，默认是true。这就意味着假如不手动修改设置文件，必定会进这个判定。内里用反射挪用了sun.misc.GC的requestLatency要领。我点进这个sun.misc.GC类内里，看到了GC日记内里谁人run的处所，看下图： 看名字这是一个保卫历程，内里挪用了system.gc()，这下可以必定的是GC日记里频仍呈现的Full GC操纵就是这里引起的(后头我又抓了许多次线程栈发明挪用GC的只有这一个类)。到这里我终于可以确定为什么GC日记内里那么多Full GC了，都是由于Tomcat设置内里加载这个内存检测的Class导致的。那有什么步伐可以停止这个呢，其后网上查了下，有这么几种要领： ① 直接去掉这个设置 ② 将上面谁人默认设置true的参数改成false，将Server.xml内里的对应那条设置中增进下面的一段：
③ 增进-XX:+ExplicitGCInvokesConcurrent设置，这个参数不会像DisableExplicitGC一样强行忽略手动挪用system.gc，而是在碰着挪用system.gc时挪用CMS垃圾接纳要领。由于上面提过CMS是搁浅最短的GC要领，这样就可以停止由full GC带来的长GC pause引起的机能题目。 颠末测试我是回收的第三个要领，到最后内存增添的题目获得了办理。最后我们看一下GC日记中CMS的耗时，看下图：
这里被我用红线划得就是mark和remark的两个阶段，由于这有这两个阶段是Stop-the-world的，可以看到耗时和Full GC比起来要短许多。 最后Tomcat的JVM设置参数被我修改为下图：
这内里有几个较量重要好用的我或许说一下： -Xloggc:gc.log -XX:+PrintGCDetails，这个参数会配置打印GC日记，这次题目，靠GC日记说明出了许多有效的对象。 -XX:+UseConcMarkSweepGC ，选用CMS作为垃圾接纳要领 -XX:+ ExplicitGCInvokesConcurrent，用这个替代了DisableExplicitGC，每次碰着system.gc时挪用一次CMS接纳，并不是直接Stop-the-world。 -XX:+UseCMSCompactAtFullCollection，在每次CMS网络器在完成垃圾接纳之后做一次内存碎片清算。 Tomcat的线程池也是可以本身设置的，包罗可接管的毗连数之类的，这里我就不睁开说了，码字也不轻松… 其他尚有许多有乐趣的可以自行相识。 总结 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
