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

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

场景分析

现场环境中,造成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-Classcom.xp.agent.main.Main
Can-Redefine-Classestrue
Can-Retransform-Classestrue
Class-Pathtrace-0.0.1-SNAPSHOT-common.jar asm-all-6.0_BETA.jar
Created-ByApache Maven 3.3.9
Build-Jdk: 1.8.0_121
Boot-Class-Pathtrace-0.0.1-SNAPSHOT-agentcore.jar

代码地址

https://github.com/xpbob/lightTrace


原文始发于微信公众号(一次编译多处运行):jstat的小伙伴---找出system.gc的调用的小工具