转载

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

在《一文带你了解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方法。

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

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

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

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

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

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

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

原文 http://www.jianshu.com/p/41f6411f34ed

正文到此结束

所属分类：编程技术 Java

本文标签： tar IDE src 类加载器数据 ThreadPoolExecutor JVM js UI final id https 配置 json IO ssl map URLs executor root cat App 线程池 java 线程 CTO ACE find 空间 http Agent
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

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

卸载时的一些坑

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流