转载自 又发生频繁FGC，这次是谁的锅
这是笨神JVMPocket群里一位名为"云何*住"的同学提出来的问题，问题现象是CPU飙高并且频繁FullGC。
重现问题
这位同学的业务代码比较复杂，为了简化业务场景，笔者将其代码压缩成如下的代码片段：
public class FullGCDemo {private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,new ThreadPoolExecutor.DiscardOldestPolicy());public static void main(String[] args) throws Exception {executor.setMaximumPoolSize(50);// 模拟xxl-job 100ms 调用一次, 原代码没有这么频繁for (int i=0; i<Integer.MAX_VALUE; i++){buildBar();Thread.sleep(100);}}private static void buildBar(){List<FutureContract> futureContractList = getAllFutureContract();futureContractList.forEach(contract -> {// do somethingexecutor.scheduleWithFixedDelay(() -> {try{doFutureContract(contract);}catch (Exception e){e.printStackTrace();}}, 2, 3, TimeUnit.SECONDS);});}private static void doFutureContract(FutureContract contract){// do something with futureContract}private static List<FutureContract> getAllFutureContract(){List<FutureContract> futureContractList = new ArrayList<>();// 问题代码这里每次只会new不到10个对象, 我这里new了100个是为了更快重现问题for (int i = 0; i < 100; i++) {FutureContract contract = new FutureContract(i, ... ...);futureContractList.add(contract);}return futureContractList;}
}
说明，为了更好的还原问题，FutureContract.java的定义建议尽量与问题代码保持一致：
- 16个BigDecimal类型属性
- 3个Long类型属性
- 3个String类型属性
- 4个Integer类型属性
- 2个Date类型属性
问题代码运行时的JVM参数如下（JDK8）：
java -Xmx256m -Xms256m -Xmn64m FullGCDemo
你也可以先自己独立思考一下这块代码问题何在。
CPU飙高
这是第一个现象，top命令就能看到，找到我们的进程ID，例如91782。然后执行命令top -H -p 91782查看进程里的线程情况：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 91784 yyapp 20 0 2670m 300m 12m R 92.2 7.8 4:14.39 java 91785 yyapp 20 0 2670m 300m 12m R 91.9 7.8 4:14.32 java 91794 yyapp 20 0 2670m 300m 12m S 1.0 7.8 0:09.38 java 91799 yyapp 20 0 2670m 300m 12m S 1.0 7.8 0:09.39 java
由这段结果可知线程91784和91785很消耗CPU。将91784和91785分别转为16进制，得到16688和16689。接下来通过执行命令命令jstack -l 91782 > 91782.log导出线程栈信息（命令中是进程ID），并在线程dump文件中寻找16进制数16688和16689，得到如下两条信息：
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f700001e000 nid=0x16688 runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f7000020000 nid=0x16689 runnable
由这两行结果可知，消耗CPU的是ParallelGC线程。因为问题代码搭配的JVM参数没有指定任何垃圾回收期，所以用的是默认的PS垃圾回收，所以这个JVM实例应该在频繁FullGC，通过命令jstat -gcutil 91782 5s查看GC表现可以验证，由这段结果可知，Eden和Old都占满了，且不再发生YGC，但是却在频繁FGC，此时的应用已经不能处理任务，相当于假死了，好可怕：
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 100.00 99.98 78.57 83.36 5 0.633 366 327.647 328.2810.00 0.00 100.00 99.98 78.57 83.36 5 0.633 371 331.965 332.5980.00 0.00 100.00 99.98 78.57 83.36 5 0.633 376 336.996 337.6290.00 0.00 100.00 99.98 78.57 83.36 5 0.633 381 340.795 341.4280.00 0.00 100.00 99.98 78.57 83.36 5 0.633 387 346.268 346.901
揪出真凶
到这里基本可以确认是有对象没有释放导致即使发生FullGC也回收不了引起的，准备dump进行分析看看Old区都是些什么妖魔鬼怪，执行命令jmap -dump:format=b,file=91782.bin 91782，用MAT分析时，强烈建议开启keep unreachable objects：
keep unreachable objects
接下来点击Actions下的Histogram，查找大对象:
histogram
下面贴出的是原图，而不是笔者的Demo代码跑出来的：
histogram view
由这段代码可知，大量的FutureContract和BigDecimal（说明：因为FutureContract中有多达16个BigDecimal类型的属性），FutureContract占了120MB，BigDecimal占了95MB。那么就可以断定问题是与FutureContract相关的代码造成的，如果是正常的JVM示例，Histogram试图最占内存的是byte[]和char[]两个数组，两者合计一般会占去80%左右的内存，远远超过其他对象占用的内存。
接下来通过FutureContract就找到上面这块buildBar方法代码，那么为什么是这块代码无法释放呢？单独把这块代码拧出来看看，这里用到了ScheduledThreadPoolExecutor定时调度，且每3秒执行一次，然而定时器中需要的参数来自外面的List<FutureContract>，这就会导致List<FutureContract>这个对象一致被一个定时任务引用，永远无法回收，从而导致FutureContract不断晋升到Old区，直到占满Old区然后频繁FullGC。
private static void buildBar(){List<FutureContract> futureContractList = getAllFutureContract();futureContractList.forEach(contract -> {// do somethingexecutor.scheduleWithFixedDelay(() -> {try{doFutureContract(contract);}catch (Exception e){e.printStackTrace();}}, 2, 3, TimeUnit.SECONDS);});
}
那么为什么会出现这种情况呢？我相信一个程序员不应该犯这样的低级错误，后来看到原生代码，我做出一个比较合理的猜测，其本意可能是想通过调用Executor executor来异步执行，谁知小手一抖，在红色框那里输入了taskExecutor，而不是executor：
problem code
解决问题
OK，知道问题的根因，想解决问题就比较简单了，将taskExecutor改成executor即可：
private static ThreadPoolExecutor executor = new ThreadPoolExecutor(50, 50, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(128));
private static void buildBar(){List<FutureContract> futureContractList = getAllFutureContract();futureContractList.forEach(contract -> {// do somethingexecutor.execute(() -> {try{doFutureContract(contract);}catch (Exception e){e.printStackTrace();}});});
}
或者将这一块直接改成同步处理，不需要线程池：
private static void buildBar(){List<FutureContract> futureContractList = getAllFutureContract();futureContractList.forEach(contract -> {// do somethingtry{doFutureContract(contract);}catch (Exception e){e.printStackTrace();}});
}