一次系统JVM 频繁Full GC，内存被占满无法回收的问题分析

 一， 问题的表现：

       我们的系统属于爬虫应用，发取各个网站的数据。上周三的下午，一次上线重启后，大约过了大半天时间，突然收到CPU负载过高的邮件，赶紧登陆堡垒机进行查看。CPU 占用率达到 300%多，系统响应速度极为缓慢。查看GC 日志，发现 一分钟内有几十次以上的FULL GC , 平均每次耗时 2,3秒钟，而且老年代一直是占满的状态，并不能进行有效的回收 。

二 ，排查方式：

     jstack 打印线程栈信息， 发现没有异常的线程信息，没有发现死锁。

     dump 堆内存，4 个G ，文件巨大。利用 MAT 打开进行分析，发现有两块可疑的发生内存泄漏的对象，一个是tomcat的守护线程，还有一部分是 系统内的线程池中的线程，这两部分占据了堆内存80%以上的空间。（图）

     执行jmap -histo  pid 查看堆中存活对象情况，如下：

发现有大量的 javaScript 相关的对象，怀疑是 htmlunit的 执行的js没有正常关闭导致的。于是产生一种思路，将正常服务器GC回收后的内存dump, 与本次有问题的dump文件中的对象进行对比，切换到MAT中的 Histogram 视图下，按照retainHeap 排序， 正常的堆 显示如下：

而内存无法GC的堆dump文件显示如下：

很显然，ThreadLocalMap  和 com.gargoylesoftware.htmlunit.html.BaseFrameElement$1这两个对象非常可疑，都有将近1.6G的对象因他们的存活而无法回收。可以看出线程池中线程的ThreadLocalMap  中有大量对象无法回收，点开 incoming reference 看看 ThreadLocalMap  看看究竟是什么东西引用了它。，

有大量的  com.gargoylesoftware.htmlunit.NicelyResynchronizingAjaxController ， 再看看 com.gargoylesoftware.htmlunit.html.BaseFrameElement$1 是被什么引用的：

显然 是 BaseFrameElement$1 引起的，他被 threadLocalmap 引用。 再观察下 BaseFrameElement$1 的 domineator tree 看看它的对象支配树内容

发现几乎每个 com.gargoylesoftware.htmlunit.html.BaseFrameElement$1 中引用的的 HtmlPage 的 webRequest 中的URL 都是 http://www.gx.10086.cn/wodeyidong/mymob/xiangdan.jsp ，发送验证码短信的链接。 因此怀疑和这个链接有关，在程序中分析这个链接中的http请求,  不在完整的加载这个页面，而是只请求和发短信相关的两个url。 重新上线后观察一段时间发现，系统运行正常，到此问题解决.

   但是到底是什么原因导致的内存无法回收呢？于是我又查看了下BaseFrameElement的源码，它有一个匿名的内部类 PostponedAction，一个由javaScript 设置的src属性 ，将被它包装成 一个延迟执行的任务，等到脚本加载完了再去执行。

而这个任务会被添加到当前线程 JavaScriptEngine实例的 threadLocal属性里，在JS的run方法最后进行执行。每次执行都会 postponedActions_.set(null)，将这些延迟任务的引用进行释放。而之所以这么多的 延迟任务保留在任务线程的threadlocal里没有被释放，猜测应该是JS执行RUN方法过程中有异常而导致的。