通过btrace排查线上频繁Full GC的case 1

概述

又是一次因为线上报警机制开启的排查问题之旅。某日，钉钉机器人疯狂报警：

接着就是申请机器权限去排查问题，既然是频繁Full GC，那我们排查问题的思路就应该是找到引起Full GC的原因。引起频繁Full GC的常见原因有这么几点：

堆外内存达到阈值，将会调用System.gc()来做一次Full GC。这里说的堆外内存主要说的是nio下的DirectByteBuffer，它会通过Unsafe接口通过os::malloc来分配内存，然后将内存的起始地址和大小存到DirectByteBuffer对象中，只有当DirectByteBuffer被回收掉之后堆外内存才可能被回收。具体堆外内存回收的细节大家可以看下笨神的JVM源码分析之堆外内存完全解读.
项目中显示或隐式的调用了System.gc()。System.gc的详情可见链接描述
老年代可用空间不够了，导致它的原因有多种，但是常见的排查思路通过mat去分析堆内存dump文件。

定位Full GC的原因

gc日志永远都是我们排查gc问题最好的工具，所以强烈建议大家在线上配置-XX:+PrintGCDetails -Xloggc:/data/logs/gc.log方便我们去定位问题。由于当前项目没有配置，只好用jstat -gccause去监测，博主监测了五分钟左右，得到如下信息:新生代、老年代、元空间内存还很多，FGC涨了9次，并且对应的LGCC都显示为System.gc.由于虚拟机参数并没有去配置-XX:MaxDirectMemorySize,所以其堆外内存受限于当前物理机内存，故我们可以通过top去查看进程占了多少内存和通过free -m查看空闲内存（当然visualvm的插件和perftools都是查看堆外内存使用情况很好的工具，不了解自行谷歌）。经过内存分析和业务分析之后，初步断定不是堆外内存导致的，而是由项目中有调用System.gc().

如何查找项目哪里有调用Full GC呢

首先对项目全局进行搜索System.gc(),如果没有查到，那么就很可能是依赖的jar包里存在调用，如何在jar包中查找呢？在这里给大家推荐一款插件Btracegithub地址。BTrace是Java的安全可靠的动态跟踪工具。他的工作原理是通过 instrument + asm 来对正在运行的java程序中的class类进行动态增强。说他是安全可靠的，是因为它对正在运行的程序是只读的。也就是说，他可以插入跟踪语句来检测和分析运行中的程序，不允许对其进行修改。因此他存在一些限制：

不能创建对象
不能创建数组
不能抛出和捕获异常
不能调用任何对象方法和静态方法
不能给目标程序中的类静态属性和对象的属性进行赋值
不能有外部、内部和嵌套类
不能有同步块和同步方法
不能有循环(for, while, do..while)
不能继承任何的类
不能实现接口
不能包含assert断言语句

根据官方声明，不恰当的使用Btrace会导致jvm崩溃，所以在上生产环境之前，一定要在本地充分验证脚本的正确性。Btrace的常见使用场景有：

分析哪些方法调用System.gc，获取其调用栈
接口性能差，分析耗时情况
当出现异常时，分析方法的运行时参数
线上有一个大对象ArrayList，查看其内容

安装使用Btrace

Btrace依赖于JDK，首先要安装好JDK并配置JDK的环境变量。

1.下载安装包

下载地址:https://github.com/btraceio/btrace/releases/tag/v1.3.11

2.解压缩

修改目录权限:

3.配置环境变量

然后source更新环境变量
4.编写btrace脚本

import static com.sun.btrace.BTraceUtils.jstack;
import static com.sun.btrace.BTraceUtils.println;
import static com.sun.btrace.BTraceUtils.str;
import static com.sun.btrace.BTraceUtils.strcat;
import static com.sun.btrace.BTraceUtils.timeMillis;import com.sun.btrace.annotations.BTrace;
import com.sun.btrace.annotations.Kind;
import com.sun.btrace.annotations.Location;
import com.sun.btrace.annotations.OnMethod;
import com.sun.btrace.annotations.TLS;
@BTrace
public class MyTest {@OnMethod(clazz = "java.lang.System", method = "gc" )public static void startMethod(){println("****************************************");jstack();println("****************************************");}@OnMethod(clazz = "java.lang.System", method = "gc", location = @Location(Kind.RETURN))public static void endMethod(){println("=========================================");jstack();println("=========================================");}
}

5.运行btrace

通过jps -l获得进程的pid，然后通过 btrace <pid> <btrace_script> >> gc.txt & 以后台任务的方式去开启btrace脚本监听对应进程，将对应的栈信息保存到gc.txt中。
6.关闭btrace

经过长达一天的监控，终于抓到了对应的调用栈：

原因是项目中用到了jxl的Workbook来做Excel相关的功能,每次关闭Workbook的时候都会调用System.gc

至此，我们就已经抓住了导致频繁Full GC的鬼了，改动方法也特别简单，在构造WorkBook的时候，将其成员变量WorkbookSettings的成员变量gcDisabled设置为true即可避免此问题，或者添加vm参数-Djxl.nogc=true（不太推荐）.