频繁FGC的真凶原来是它

jiezi

5 年前

上周排查了一个线上问题，主要现象是 CPU 占用过高，jvm old 区占用过高，同时频繁 fgc，我简单排查了下就草草收场了，但是过后我对这个问题又进行了复查，发现问题没有那么简单，下面跟着我一起分析一下到底是怎么回事？

一定要先读完上篇文章 cpu 使用率过高和 jvm old 占用过高排查过程

复查原因

事后再看 dump 文件注意到最大的对象是一个 ArrayList，里面几乎都是 ElasticSearchStatusException 对象

可是发生这个异常的操作上次已经被我定位到了，数据漏斗只有产品、运营等内部人员使用，通过使用频率推测，不应该有那么多对象。我猜想是不是代码中存在死循环，但没有找到。没办法只能在测试环境进行场景复现了。

复原现场

通过上次排查到是 es 查询了不存在的索引导致异常，所以就把查询 es 的索引写死一个不存在的，最初尝试写个单测，但一直不能复现问题，所以只好部署到测试环境，在本地通过 远程 debug 调试程序

远程 debug 到断点时，发现源码对不上

然后发现有可选择的源码，这里是关键

从 org.apache.commons.lang:2.5jar 包切换到 springsource.org.apache.commons.lang:2.1.0 包后，竟然能够和测试环境对得上，可是代码中明明引用的 commons.lang:2.5 的包，这里说明在项目中类加载的时候，ExceptionUtils 这个 class 文件并不是从 commons.lang 中加载的，而是从 springsource 包中加载的 关于类文件加载的问题我们先放到后面，先找代码的问题

看到这里，眼尖的朋友应该已经发现了 bug 的所在，那么恭喜你。如果没发现的朋友，不要着急，跟我一步一步来。我们继续 debug 跟进代码的 getCause 方法，可以看到通过遍历异常名字的数组验证是否在抛出的异常中存在

这些异常方法中的 getRootCause 方法，存在 ElasticSearchStatusException 的父类 ElasticsearchException 中

我们看下这个方法，主要找最根本的异常原因，有则返回，没有就返回当前的异常

继续跟代码，cause 不为 null，返回这个异常

bug 代码定位

这个 getThrowables 方法，里面有个 while 循环，判断条件只进行了非空判断，不为 null 就添加到 list 中，注意观察我截图的时刻，list 的大小 8 万多，其实远远不止 会看开头 dump 文件的大对象，是一个 ArrayList，里面有大量的 ElasticSearchStatusException 对象

其实到这里已经定位到了 FGC 的真凶，判断条件没有排除返回的异常是已经添加到 list 中的异常，所以会一直循环添加，造成堆内存占用满了，FGC 回收不掉这些对象，因为 ArrayList 一直持有他们的引用

正确代码 应该如下面这样，所以开源工具库也是会有 bug 的，用的时候多加注意

public static Throwable[] getThrowables(Throwable throwable) {List list = new ArrayList();
        // 这里的判断条件应该加上 list.contains(throwable) == false
        while (throwable != null && list.contains(throwable) == false) {list.add(throwable);
            throwable = ExceptionUtils.getCause(throwable);
        }
        return (Throwable[]) list.toArray(new Throwable[list.size()]);
    }

本来我们就没想用 springsource 的方法，只是类加载的时候加载错了，那看下 commons.lang 包下的方法是否正确呢？可以看到这个包的方法是正确的，考虑到了这个问题

springsource 的 commons.lang 包在 2.2 版本已经修复了这个问题 jar 包最好引用最新的

上面我们留了一个 jvm 加载 class 文件的问题，我们知道 jvm 加载 class 的时候，如果存在包名和类名完全一样，先加载一个后，另外的就不会再被加载了。

经查看两个 ExceptionUtils 确实包名类名完全一致

其实通过前面的 debug 和代码分析，已经能确定项目加载的 ExceptionUtils.class 文件来自 springsource 包，但还是想通过一定手段验证一下。

其实 jvm 提供类类似的功能参数，修改项目启动脚本，添加 jvm 参数 -XX:+TraceClassLoading 然后重启项目并继让异常重现【这里要让触发异常重现，是因为是运行时异常】，并查看日志，查看 ExceptionUtils.class 的加载信息

可以看到确实和我们推测的一样

其实这里还可以深入研究 jvm 的类加载机制，类加载器加载顺序，双亲委派模型等

通过 mvn dependency:tree 查看 jar 包依赖情况，排除掉不用的 jar 包

到这里这个问题的排查应该告一段落了，从排查过程中学到了不少，场景复现，梳理思路，用文章分享出来虽说码字不易很耗时，但这是对自己的一种总结，里面还是有很多乐趣与收获的。

后续会继续分享一些和广告系统相关的文章，敬请期待！

欢迎关注公众号【每天晒白牙】，获取最新文章，我们一起交流，共同进步！

频繁FGC的真凶原来是它

频繁 FGC 的真凶原来是它

复查过程

复查原因

复原现场

class 文件加载问题

如何解决

结尾