线上GC异常排查

线上GC异常排查

1.现象

最近去线上看了下gc情况，发现出现频繁的fullGC。问题如下图：

gc情况.jpg

然后查看了下GC原因，如下：

gc原因图.jpg

2.分析

根据上面两张图，可以看出主要是老年代进行了频繁的CMSGC。而CMS回收的前提条件就是老年代达到一定的容量。这个容量可以根据jvm参数CMSInitiatingOccupancyFraction进行设置。本项目的jvm配置如下：
-Xms4096m -Xmx4096m -Xmn3072m -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80
根据上面配置可以看出，老年代的容量为1G，且老年代达到80%的时候进行CMS回收。而根据上图可以发现老年代的占用率一直在80%以上。每次回收基本上都没有释放空间。所以一直在频繁的出发CMS回收算法。

3.排查

依据上面的推断，使用命令jmap -dump:live,format=b,file=heap.hprof pid触发fullGC，并dump内存快照。因为本次内存主要是老年代频繁GC导致的，而且每次回收都没有回收到有效空间。所以才直接加上live属性，防止年轻代对象干扰结果。然后使用mat分析内存泄漏如下：

heap直方图

根据图中shallow heap和Retained heap可看出占用内存最大的就是char数组。而thread、thread local还有StringBuilder都可能指向的就是char[]数组对象。下图也验证了这个猜想。

Thread对象占用内存列表

通过Thread对象找到StringBuilder对象

StringBuilder对象列表

而单个的StringBuilder对象中的内容是什么呢？

单个StringBuilder对象

根据上图可以看出来，StringBuilder对象中主要就是我们的打印的日志了。所以整体上来说。是日志打印的时候用到了StringBuilder作为临时日志存储对象，相当于一个缓存。
那么根据上图可以推算出内存泄漏的路径为，Thread对象-->ThreadLocal.ThreadLocalMap对象-->threadLocal$Entry[]-->threadLocal$Entry-->StringBuilder对象。
有了上面的路径，就知道了内存泄漏的对象主要是在ThreadLocal中了。那么我们就需要反向从StringBuilder找到对应的ThreadLocal。排查步骤如下图：

第一步找到引用StringBuilder的对象.png

第一步展示效果

第二步找到对应的ThreadLocalMap$Entry查看他指向的对象.png

第二步展示效果

第三步引用threadlocal的对象.png

第三步效果图

步骤描述：
1.右键某个StringBuilder对象，选择list objects-->with incoming references（也就是找到指向当前StringBuilder对象的对象）
2.打开引用链，找到引用当前StringBuilder的ThreadLocal$ThreadLocalMap$Entry对象。然后右键，选择list objects-->with outgoing references（找到ThreadLocal$ThreadLocalMap$Entry对象引用的对象）
3.找到当前ThreadLocal$ThreadLocalMap$Entry对象的属性，referent属性，右键list objects-->with incoming references（因为ThreadLocal$ThreadLocalMap$Entry类继承了弱引用，其中的threadlocal对象就是在referent属性中。所以此步骤是找到指向threadlocal对象的所有引用）
因为指向threadLocal的对象较多，所以需要排除很多ThreadLocal$ThreadLocalMap$Entry对象，最终我们找到了哪个我们期望的引用org.apache.logging.log4j.core.layout.AbstractStringLayout

4.代码分析

接下来查看代码AbstractStringLayout。通过查找发现，我们这个类属于log4j的。查看代码发现threadLocal就是在这里使用的

threadlocal引用地址

而代码中threadlocal使用到的地方只有下图这个地方：

threadlocal使用的地方

通过断点发现，日志打印的时候，会先在StringBuilder中生成，而StringBuilder是存在于当前线程中的。每次打印新的日志的时候，都是调用下result.setLength(0)方法，将原有的日志内容置空。而StringBuilder的这个方法，只会count指针置为0，实际并不会释放StringBuilder内value占用的内存。所以才导致了内存的泄漏。(这里强调下，本项目使用的log4j的版本是2.5)

5.解决问题

发现了问题就很容易解决了，通过查询，只需要将log4j升级即可解决这个问题(没有挨个查看具体是那个版本解决的，但是就遇到过的2.8.2已经 解决了)。本项目直接使用了2.13.2

先来看下解决之后的效果吧。
1.内存使用率

gc内存占用率修复前.jpg

gc内存占用率修复后.jpg

根据上面两张图，可以看出来修复前后差不多差了百分之7%左右，而内存总量为8G，所以前后相差差不多560M左右。
2.cpu使用率

gc前后cpu占用情况.jpg

根据上图可看出，修复前cpu使用差不多为18%左右，修复后为4%左右，前后相差14左右，效果还是很明显的

3.gc情况

gc修复之后.jpg

gc修复后原因.jpg

修复后fullGC只有六次，而且正常的GC原因都是Allocation Failure.

4.为什么将log4j升级之后就可以解决呢，看下源码如下：

protected static StringBuilder getStringBuilder() {
        if (AbstractLogger.getRecursionDepth() > 1) { // LOG4J2-2368
            // Recursive logging may clobber the cached StringBuilder.
            return new StringBuilder(DEFAULT_STRING_BUILDER_SIZE);
        }
        StringBuilder result = threadLocal.get();
        if (result == null) {
            // 初始化StringBuilder的长度为1024
            result = new StringBuilder(1024);
            threadLocal.set(result);
        }
        // 主要就是这里进行了缩容
        trimToMaxSize(result);
        result.setLength(0);
        return result;
    }

最主要的改进就是上面的trimToMaxSize方法，再看下这个方法：

// AbstractStringLayout的方法
protected static void trimToMaxSize(final StringBuilder stringBuilder) {
    // 第二个参数的获取，是根据这是的log4j的属性log4j.layoutStringBuilder.maxSize和1042取较大值
    // 这里还有可能不设置属性，取到2048
    StringBuilders.trimToMaxSize(stringBuilder, Math.max(1024, size("log4j.layoutStringBuilder.maxSize", 2 * 1024)));
}
 
// StringBuilders的方法
public static void trimToMaxSize(final StringBuilder stringBuilder, final int maxSize) {
    if (stringBuilder != null && stringBuilder.capacity() > maxSize) {
        stringBuilder.setLength(maxSize);
        // 金融StringBuilder中去进行缩容
        stringBuilder.trimToSize();
    }
}

// StringBuilder的方法
public void trimToSize() {
    // 这里就是具体的缩容了
    if (count < value.length) {
        value = Arrays.copyOf(value, count);
    }
}

通过上面的可以看到，每次在获取当前线程的StringBuilder的时候，都会做一个缩容的动作。当然如果容量没有达到上限的话，是不需要缩容的。

5. 其实这个还可以再做优化，就是将6次fullGC进行优化。。

6.解决启动时进行的fullGC

1.项目启动时使用参数-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:mygc.log
2.查看mygc.log，以及元空间使用率，信息如下

程序启动后的垃圾收集情况

元空间使用率及类加载率

根据上图可以看出来，项目启动时，进行了5次FullGC（因为是本地复现的，所以是5次），而原因都是Metadata GC Threshold。而且回收之后metaspace空间都会进行一个扩容。所以问题就是我们的metaspace空间初始容量不足，导致了启动过程中需要不断扩容metaspace。
使用参数java -XX:+PrintFlagsInitial发现，metaspace的初始值为21810376b，也就是差不多21M，而图中我们的元空间占用已经250M了。根据图中可以看出，metaspace的扩容路径为21->34->58->97->162->250。所以每次扩容的系数差不多是1.6倍左右。这个具体的扩容机空间算法需要后期研究下。
3.问题原因找到了，只需要在启动的时候，加上-XX:MetaspaceSize=256M就可以防止扩容了。注意参数MaxMetaspaceSize的设置需要慎重，最好先不要设置这个参数，后期上线观察之后再进行决定。否则可能会造成线上频繁FullGC。当然也可以进行一些预估。预估的话可以参考本文的参考

参考

深入理解堆外内存 Metaspace