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

场景分析

现场环境中,造成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

代码地址

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

https://github.com/xpbob/lightTrace

上一篇:如何对抗勒索软件即服务?


下一篇:.Net+SQL Server企业应用性能优化笔记4——精确查找瓶颈