jstat的小伙伴---找出system.gc的调用的小工具

现场环境中，造成gc频繁的可能性之一就是通过system.gc主动调用了gc。这种情况出现在开发人员业务代码，或者是jdk自身的代码中（例如nio）。我们可以通过jstat -gccause查看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

大佬如果喜欢，可以点个星鼓励一下。

https://github.com/xpbob/lightTrace

> 原创首发于慕课网