安徽网新科技有限公司 网站开发,寻找富阳网站建设,深圳做h5网站,wordpress 转移文章转载自 Java Agent的隔离实现以及卸载时一些坑
在《一文带你了解Java Agent》中#xff0c;让大家了解了Java Agent的来龙去脉#xff0c;当通过attach方式去动态加载一个Java Agent时#xff0c;Agent中的类会被加载到业务的虚拟机中#xff0c;在使用完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());}Overrideprotected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException {final Class? loadedClass findLoadedClass(name);if (loadedClass ! null) {if (resolve) {resolveClass(loadedClass);}return loadedClass;}// 优先从parentSystemClassLoader里加载系统类避免抛出ClassNotFoundExceptionif (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 pidAgent的类果然没了那个开心。 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);
最终取消这个特性每次序列化都去创建一块内存这样就可以避免这个问题又可以快乐的回收了。
后面还有更多的坑等着去填越填越开心...
