Java Agent的隔离实现以及卸载时一些坑

栏目: Java · 发布时间: 6年前

内容简介:在《一文带你了解Java Agent》中,让大家了解了Java Agent的来龙去脉,当通过attach方式去动态加载一个Java Agent时,Agent中的类会被加载到业务的虚拟机中,在使用完Agent的之后,如果想卸载这些无用的类,怎么实现?这里就涉及到如何回收Perm区、或者Metaspace中已经加载的类了,如果一个类的类加载器对象没有GC Root关联,那么可以通过FGC的方式回收这些类。不过,如果通过JVM内部的类加载器比如AppClassLoader去加载这些类的话,可能永远也不能回收了,

在《一文带你了解Java Agent》中,让大家了解了Java Agent的来龙去脉,当通过attach方式去动态加载一个Java Agent时,Agent中的类会被加载到业务的虚拟机中,在使用完Agent的之后,如果想卸载这些无用的类,怎么实现?

这里就涉及到如何回收Perm区、或者Metaspace中已经加载的类了,如果一个类的类加载器对象没有GC Root关联,那么可以通过FGC的方式回收这些类。不过,如果通过JVM内部的类加载器比如AppClassLoader去加载这些类的话,可能永远也不能回收了,所以得通过自定义的类加载器去实现Agent类的加载动作,因为自定义的类加载器对象,我们可以自己控制。

下面是自定义类加载器的实现

public class AgentClassLoader extends URLClassLoader {

    public AgentClassLoader(URL[] urls) {
        super(urls, ClassLoader.getSystemClassLoader().getParent());
    }

    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        final Class<?> loadedClass = findLoadedClass(name);
        if (loadedClass != null) {
            if (resolve) {
                resolveClass(loadedClass);
            }
            return loadedClass;
        }

        // 优先从parent(SystemClassLoader)里加载系统类,避免抛出ClassNotFoundException
        if (name != null && (name.startsWith("sun.") || name.startsWith("java."))) {
            return super.loadClass(name, resolve);
        }

        // 先从agent中加载
        try {
            Class<?> aClass = findClass(name);
            if (resolve) {
                resolveClass(aClass);
            }
            return aClass;
        } catch (Exception e) {
            // ignore
        }
        return super.loadClass(name, resolve);
    }
}

这样,通过AgentClassLoader加载的类,就可以和业务的类完全隔离开,在需要回收这些类的时候,只要把AgentClassLoader对象和GC root的关联完全掐断就行。

不过用了AgentClassLoader之后,还是遇到了一些坑,比如在Agent中使用Cat的时候,因为Cat是单例模式,都是通过 Cat.logEvent 这种方式使用,所以在第一次使用Cat的时候,Cat内部会进行初始化,比如系统信息上报逻辑。因为业务逻辑在使用Cat的时候,已经初始化过了一次,在Agent内部使用时,因为是通过AgentClassLoader加载的,又是一个全新的Cat,相当于那些上报逻辑又初始化了一次,这这种明显是不行的,那如何在Agent中可以使用业务加载的那个Cat对象呢?

后来想到了一个解决方案,通过一个CatAdapt封装了一下Cat

public class CatAdapter {

    private static final Logger logger = LoggerFactory.getLogger(CatAdapter.class);
    private static Method logEvent;

    public static void init(ClassLoader classLoader) {
        try {
            Class catClazz = Class.forName("com.dianping.cat.Cat", true, classLoader);
            logEvent = catClazz.getMethod("logEvent", String.class, String.class);
        } catch (Exception e) {
            logger.error("cat adapter init failed", e);
        }
    }

    public static void logEvent(String type, String name) {
        if (logEvent != null) {
            try {
                logEvent.invoke(null, type, name);
            } catch (Exception e) {
               // ignore
            }
        }
    }
}

在Agent初始化入口的agentmain方法中,获取当前线程的classLoader

ClassLoader currentClassLoader = Thread.currentThread().getContextClassLoader();
Class catAdapter = agentLoader.loadClass("com.**.**.CatAdapter");
Method catAdapterInit = catAdapter.getMethod("init", ClassLoader.class);
catAdapterInit.invoke(null, currentClassLoader);

又通过agentLoader去加载CatAdapter类,在init方法中,通过当前线程的classLoader去加载真正的Cat类,这时拿到的Cat的class对象和业务的Cat class对象是同一个,从而避免了上述问题,在Agent内部就可以通过CatAdapter实现Cat方法的代理调用,实现数据的埋点。

卸载时的一些坑

为了验证执行FGC时,是否可以把无用的类回收,遇到了下面这些坑。

1、很单纯的以为把agentLoader设置为null,我就可以快乐的回收了,执行了 jmap -histo:live pid 之后,惊喜的发现,Agent的类还在。

2、为了看下为什么没有回收,把堆对象dump下来,通过mat工具进行分析,找了一个Agent的类,发现其对象正被agentLoader对象拽着,顺腾摸瓜,发现agentLoader被线程池的线程拽着,这下明白了,需要把这些线程池给shutdown掉

3、因为在Agent初始化的时候,创建了几个线程池处理一些内部逻辑,所以要卸载Agent的时候,这些线程池必须shutdown。

4、把线程池shutdown之后,继续使用 jmap -histo:live pid ,发现这些类特么还在,真是顽固啊。dump下来,继续分析,发现agentLoader还被一个 Finalizer 对象给勾着!这是为啥,为什么有Finalizer对象勾着它?按照我的理解,只有重写了finalize方法的类才会有Finalizer对象,一瞬间,我怀疑是不是线程池的类重写了finalize方法,一查还真是,在 ThreadPoolExecutor 类中重写了finalize方法。

Java Agent的隔离实现以及卸载时一些坑

5、重写了finalize方法,这种情况理论上要经过两次GC才会被回收,执行了两次 jmap -histo:live pid ,Agent的类果然没了!!!那个开心。

6、后面又一次不经意的发现又无法回收了,又只能dump下来,继续分析,这次agentLoader对象被业务线程的threadLocal对象给拽着了,死都不放手。

这一次真的查了好久,因为不好复现,前前后后验证了多次,发现在使用了Agent的Mock功能之后,就会出现这个问题,Mock功能会根据业务配置的String字符串,通过jackson框架反序列化成一个对象并返回。

jackson在序列化的时候,需要开辟一块内存空间,为了能够重复利用这块空间,jackson默认把这个内存空间封装成一个SoftReference保存在ThreadLocal中。

Java Agent的隔离实现以及卸载时一些坑

这样每个线程都有一块内存可以重复使用,这原本是好事,但是在我们这,变成了一只暗搓搓的手,死死抓着agentLoader不放,导致了所有类都不能回收。

JsonFactory f = new JsonFactory();
f.disable(JsonFactory.Feature.USE_THREAD_LOCAL_FOR_BUFFER_RECYCLING);

最终通过取消这个特性,每次序列化都去创建一块内存,这样就可以避免这个问题,又可以快乐的回收了。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

活着就为改变世界

活着就为改变世界

[美] 杰弗里·扬、威廉·西蒙 / 蒋永军 / 中信出版社 / 2010-6 / 39.00元

内容简介 苹果公司CEO史蒂夫•乔布斯这个一直活在自己想象的世界里的创业奇才,经历过各种挫折与失落,但他那无所畏惧、敢于承担的个性让他一直努力实践着自己的价值观,总能为他的离奇想法找到解决问题的办法。 本书两位作者通过深入访谈和资料调查,揭秘了许多乔布斯个人的创业经历和家庭变故,为大家塑造了一个活生生的“乔布斯式”的鲜活人物,描述了一个个充满传奇色彩的商业奇迹,真实地再现了乔布斯几十年......一起来看看 《活着就为改变世界》 这本书的介绍吧!

URL 编码/解码
URL 编码/解码

URL 编码/解码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换