场景分析
现场环境中，造成gc频繁的可能性之一就是通过system.gc主动调用了gc。这种情况出现在开发人员业务代码，或者是jdk自身的代码中（例如nio）。我们可以通过jstat -gccause查看gc的原因，如果真的是system.gc，那么找出调用的代码就是继续解决问题的关键。
查看system.gc的调用
如果说查看代码调用，那么jstack就是首选，仔细想想，代码的触发时机不定，怎么才能去在合适的时候打印堆栈呢，最简单的想法就是定时的去调用，这个方法是有用的，只不过在频繁调用的时候，是可以捕获到的。可是万一不频繁调用呢。
当我们想知道自己的代码在什么时候被调用，那么最好的方式就是在自己的方法里去打印堆栈。这样就知道是谁调用的了，也不用担心是调用的时机等等。
解决方案也就出来了，那就是在system.gc调用的时候顺便打印一下堆栈。system是jdk的类，可以自己编写一个system类替换掉jdk的，只不过不想用的时候还得改回来。为了灵活我们选择动态修改字节码。
字节码改造
我们先想想打印堆栈的代码
StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
for (StackTraceElement element : stackTrace) {
System.out.println(element);
}
现在呢，我们就在system.gc前调用这个方法。这里修改字节码的方式，我们使用asm。
InsnList list = new InsnList();
list.add(getLabelNode());
list.add(new MethodInsnNode(INVOKESTATIC, "com/xp/agent/core/ThreadInfo", "getStack", "()V", false));
insns.insert(list);
修改完就大功告成。
细节补充
字节码是改成了，但是我们的那个类路径得让加载system类的classloader(bootstrapclassloader)找到我们的类。否则会抛出classnotfind或者noclassdefineerror。这里我们通过增加配置文件的方式。
Agent-Class: com.xp.agent.main.Main
Can-Redefine-Classes: true
Can-Retransform-Classes: true
Class-Path: trace-0.0.1-SNAPSHOT-common.jar asm-all-6.0_BETA.jar
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_121
Boot-Class-Path: trace-0.0.1-SNAPSHOT-agentcore.jar
代码地址
大佬如果喜欢，可以点个星鼓励一下。