排查实战之ClassLoader动态加载插件无法回收引用排查

最近在看jvm-sandbox的一些功能,参考着实现了动态加载Jar包插件的功能,但是实现的这个功能有一个比较严重的问题,就是类加载完毕之后,当你需要覆盖或者卸载时候,该类加载器的引用是无法被回收的。也就是说由这个类加载器加载之后,无法卸载,这个加载器一直存在。

如果一旦新增或者覆盖的jar包过多,会导致类加载器一直堆积。严重点会发生泄漏的风险。

基于以上场景开始了漫漫排查路。

代码回顾

1. 自定义的类加载器

这个加载器的主要功能是负责路由,也是参考的jvm-sandbox
主要目的是将加载器隔离:比如主加载器A,插件加载器为B

同样一个接口A加载器肯定是有的,B加载器也有,如果各自加载那么同一个类也会出现不一致。所以为了保证全局唯一,有一些特定的类B中即便有的话也需要从A中去加载。这就是这个路由的意义。

/**
 * 可路由的URLClassLoader
 *
 * @author [email protected]
 */
public class ManagerClassLoader extends URLClassLoader {

    private final Logger logger = LoggerFactory.getLogger(ManagerClassLoader.class);
    private final Routing[] routingArray;

    public ManagerClassLoader(final URL[] urls,
                              final Routing... routingArray) {
        super(urls);
        this.routingArray = routingArray;
    }

    public ManagerClassLoader(final URL[] urls,
                              final ClassLoader parent,
                              final Routing... routingArray) {
        super(urls, parent);
        this.routingArray = routingArray;
    }

    @Override
    public URL getResource(String name) {
        URL url = findResource(name);
        if (null != url) {
            return url;
        }
        url = super.getResource(name);
        return url;
    }

    @Override
    public Enumeration getResources(String name) throws IOException {
        Enumeration urls = findResources(name);
        if (null != urls) {
            return urls;
        }
        urls = super.getResources(name);
        return urls;
    }

    @Override
    protected Class loadClass(final String javaClassName, final boolean resolve) throws ClassNotFoundException {
        // 优先查询类加载路由表,如果命中路由规则,则优先从路由表中的ClassLoader完成类加载
        if (ArrayUtils.isNotEmpty(routingArray)) {
            for (final Routing routing : routingArray) {
                if (!routing.isHit(javaClassName)) {
                    continue;
                }
                final ClassLoader routingClassLoader = routing.classLoader;
                try {
                    System.out.println("被转发的类名称:" + javaClassName);
                    return routingClassLoader.loadClass(javaClassName);
                } catch (Exception cause) {
                    // 如果在当前routingClassLoader中找不到应该优先加载的类(应该不可能,但不排除有就是故意命名成同名类)
                    // 此时应该忽略异常,继续往下加载
                    // ignore...
                }
            }
        }

        // 先走一次已加载类的缓存,如果没有命中,则继续往下加载
        final Class loadedClass = findLoadedClass(javaClassName);
        if (loadedClass != null) {
            return loadedClass;
        }

        try {
            Class aClass = findClass(javaClassName);
            if (resolve) {
                resolveClass(aClass);
            }
            return aClass;
        } catch (Exception cause) {
            System.out.println("================================" + javaClassName);
            return super.loadClass(javaClassName, resolve);
        }
    }

    /**
     * 类加载路由匹配器
     */
    public static class Routing {

        private final Collection regexExpresses = new ArrayList();
        private ClassLoader classLoader;

        /**
         * 构造类加载路由匹配器
         *
         * @param classLoader       目标ClassLoader
         * @param regexExpressArray 匹配规则表达式数组
         */
        public Routing(final ClassLoader classLoader, final String... regexExpressArray) {
            if (ArrayUtils.isNotEmpty(regexExpressArray)) {
                regexExpresses.addAll(Arrays.asList(regexExpressArray));
            }
            this.classLoader = classLoader;
        }

        /**
         * 当前参与匹配的Java类名是否命中路由匹配规则
         * 命中匹配规则的类加载,将会从此ClassLoader中完成对应的加载行为
         *
         * @param javaClassName 参与匹配的Java类名
         * @return true:命中;false:不命中;
         */
        private boolean isHit(final String javaClassName) {
            for (final String regexExpress : regexExpresses) {
                try {
                    if (javaClassName.matches(regexExpress)) {
                        return true;
                    }
                } catch (Throwable cause) {
                    cause.printStackTrace();
//                    logger.warn("routing {} failed, regex-express={}.", javaClassName, regexExpress, cause);
                }
            }
            return false;
        }

    }


    @Override
    protected void finalize() throws Throwable {
        // 一旦这个类被回收的话,会被回调。
        System.out.println("ManagerClassLoader 终于被回收了!");
        super.finalize();
    }
}

2. 构建测试

这个测试比较简单:

  • 构建一个Map来管理加载的类
  • 每次加载一个ClassLoader的时候,先清空上一个。

为了简单方便,管理器永远只有一个加载器。但是为了查看效果,你可以重复一直加载。

  • 控制台输入1 的时候会手动加载一个jar包中的类。2 卸载jar包中的类和加载器. 3 触发GC看是否会被回收掉。

/**
 * @author liukaixiong
 * @Email [email protected]
 * @date 2021/12/27 - 17:27
 */
public class ClassLoaderTest {

    public static void main(String[] args) throws Exception {
        File file = new File("E:\\study\\sandbox\\sandbox-module\\manager-plugins\\cat-plugin-1.3.3-jar-with-dependencies.jar");
//        URL urls = new URL("file:C:/Users/liukx/AppData/Local/Temp/manager_plugin124980413499729388.jar");
        Map cacheMap = new HashMap<>();

        Scanner input = new Scanner(System.in);
        while (true) {
            System.out.println("请输入执行 [1 : 加载 , 3 : 卸载]");
            int next = input.nextInt();
            System.out.println("接收到的指令:" + next);

            if (1 == next) {
                // 先清除上一个加载器
                clearClassLoader(cacheMap);
                // 加载一个新的类加载器
                AnnotationConfigApplicationContext applicationContext = newManager(file);
                cacheMap.put("A", applicationContext);
            } else if (2 == next) {
                clearClassLoader(cacheMap);
            } else if (3 == next) {
                System.gc();
                System.out.println("触发了一次GC操作!");
            }
        }
    }
    
    // 先清空上一个加载器。
    private static void clearClassLoader(Map cacheMap) throws IOException {
        AnnotationConfigApplicationContext context = cacheMap.remove("A");
        Optional.ofNullable(context).ifPresent((c) -> {
            ManagerClassLoader classLoader = (ManagerClassLoader) c.getClassLoader();
            try {
                Objects.requireNonNull(classLoader).close();
            } catch (IOException e) {
                e.printStackTrace();
            }
            System.out.println("清除缓存");
        });
    }
    
    // 实际中的自定义管理器
    private static AnnotationConfigApplicationContext newManager(File file) {
        List includeClass = new ArrayList<>();
        includeClass.add("^com\\.sandbox\\.manager\\.api\\..*");
        includeClass.add("^com\\.alibaba\\.jvm\\.sandbox\\.api\\..*");
       //  includeClass.add("^com\\.lkx\\..*"); //todo 原来如此
//        // includeClass.add("^org\\.apache\\.commons\\.lang3\\..*");
        includeClass.add("^org\\.springframework\\..*");
//        includeClass.add("^java\\..*");

        ManagerClassLoader urlClassLoader = new ManagerClassLoader(new URL[]{builderUrl(file)}, new ManagerClassLoader.Routing(
                ClassLoaderTest.class.getClassLoader(),
                includeClass.toArray(includeClass.toArray(new String[0]))));
        AnnotationConfigApplicationContext pluginApplicationContext = new AnnotationConfigApplicationContext();
        pluginApplicationContext.setClassLoader(urlClassLoader);
        pluginApplicationContext.scan("com.sandbox.application.plugin");
        pluginApplicationContext.refresh();

        Trace bean = pluginApplicationContext.getBean(Trace.class);
        String id = bean.getId();
        System.out.println(">>>>> 执行 :: " + id);
        return pluginApplicationContext;
    }
    // 简单的自定义加载方式
    private static AnnotationConfigApplicationContext newMyClassLoader(File file) {
        MyClassLoader urlClassLoader = new MyClassLoader(new URL[]{builderUrl(file)});
        AnnotationConfigApplicationContext pluginApplicationContext = new AnnotationConfigApplicationContext();
        pluginApplicationContext.setClassLoader(urlClassLoader);
        pluginApplicationContext.scan("com.sandbox.application.plugin");
        pluginApplicationContext.refresh();
        return pluginApplicationContext;
    }
    // 最简单的加载方式
    private static AnnotationConfigApplicationContext newURLClassloader(File file) {
        URLClassLoader urlClassLoader = new URLClassLoader(new URL[]{builderUrl(file)}, ClassLoaderTest.class.getClassLoader());
        AnnotationConfigApplicationContext pluginApplicationContext = new AnnotationConfigApplicationContext();
        pluginApplicationContext.setClassLoader(urlClassLoader);
        pluginApplicationContext.scan("com.sandbox.application.plugin");
        pluginApplicationContext.refresh();
        return pluginApplicationContext;
    }

    private static URL builderUrl(File file) {
        try {
            // 每次都是构建一个新的临时的jar
            File tempFile = File.createTempFile("manager_plugin", ".jar");
            tempFile.deleteOnExit();
            FileUtils.copyFile(file, tempFile);
            return new URL("file:" + tempFile.getPath());
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }
}

执行右键,运行main方法

  • 反复输入1 不断重复加载。

这个时候我用的是JProfile、其实还可以查看java自带的jvisualvm.exe工具查看。

这里还是稍微记录一下jvisualvm.exe的使用方式:

  • 位置是在C:\Program Files\Java\jdk1.8.0_261\bin\jvisualvm.exe。可以根据自己的java安装环境去查找。
  1. 你运行了程序,直接点击jvisualvm.exe打开。

这个时候你会看到虚拟机的运行环境,但是这个时候我们需要看某个实例的运行个数时。最好是在运行java程序中加入
-Djava.rmi.server.hostname=127.0.0.1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=4444 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

开启一个可远程观测的端口。

image.png

这个时候,你基本上可以看到实例的加载情况,但是无法追查到引用数据。

3. 使用jprofile去追查

Jprofile 11的下载
纯干货:内存溢出通过Jprofile排查思路以及实践总结
有需要的先了解一下上面的排查文章。

1. 定位java应用程序
image.png

点击OK。这个时候虚拟机的信息基本上都展现出来了。

2. 查看存活的类
image.png

定位你需要关注的类

3. 选择你关注的类,并生成快照
image.png

image.png

这个时候基本上中和类的总数和大小引入眼帘。

4. 追踪这个类的引用类

右键你选择的类

image.png

image.png

这个时候,有多少个实例就会有多少条记录。
image.png

其实我们目前按照正常情况来讲,触发GC之后应该只剩一个。但是现在显然不是。

这种情况一定是该实例引用被外部持有,没有被释放掉,导致GC无法回收这个实例。

随便打开一个看看:

关键引用图

image.png

说实话,一开始真看不出啥,确实没啥经验,只能慢慢摸索呗~

没有思路,这时我们可以换种方式: 排除法


遇到不会的,先搭一个简单的demo,一步一步朝着我们实际的实现出发。

越简单的案例越能快速反应问题,复杂的东西导致的因素会很多。

  1. 先写了一个newURLClassloader 方法,从URLClassLoder出发,发现没问题,能被回收。
  2. 然后在手写了一个简单自定义的方法newMyClassLoader,发现也没问题。
public class MyClassLoader extends URLClassLoader {


    public MyClassLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }

    public MyClassLoader(URL[] urls) {
        super(urls);
    }

    public MyClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
        super(urls, parent, factory);
    }

}

嗯,那一定就是实现的方式出了毛病。

  1. 然后从实现的ManagerClassLoader类中把实现方法loadClass给注释掉了,发现居然是OK的。

嗯,越来越近了。

细看了一下loadClass方法:

发现也没啥,就是特定的路径使用特定的类加载器加载。

protected Class loadClass(final String javaClassName, final boolean resolve) throws ClassNotFoundException {
        // 优先查询类加载路由表,如果命中路由规则,则优先从路由表中的ClassLoader完成类加载
        if (ArrayUtils.isNotEmpty(routingArray)) {
            for (final Routing routing : routingArray) {
                if (!routing.isHit(javaClassName)) {
                    continue;
                }
                final ClassLoader routingClassLoader = routing.classLoader;
                try {
                    System.out.println("被转发的类名称:" + javaClassName);
                    return routingClassLoader.loadClass(javaClassName);
                } catch (Exception cause) {
                    // 如果在当前routingClassLoader中找不到应该优先加载的类(应该不可能,但不排除有就是故意命名成同名类)
                    // 此时应该忽略异常,继续往下加载
                    // ignore...
                }
            }
        }

        // 先走一次已加载类的缓存,如果没有命中,则继续往下加载
        final Class loadedClass = findLoadedClass(javaClassName);
        if (loadedClass != null) {
            return loadedClass;
        }

        try {
            Class aClass = findClass(javaClassName);
            if (resolve) {
                resolveClass(aClass);
            }
            return aClass;
        } catch (Exception cause) {
            System.out.println("================================" + javaClassName);
            return super.loadClass(javaClassName, resolve);
        }
    }

应该就是使用方式的问题。

private static AnnotationConfigApplicationContext newManager(File file) {
        List includeClass = new ArrayList<>();
        includeClass.add("^com\\.sandbox\\.manager\\.api\\..*");
        includeClass.add("^com\\.alibaba\\.jvm\\.sandbox\\.api\\..*");
       //  includeClass.add("^com\\.lkx\\..*"); //todo 原来如此
//        // includeClass.add("^org\\.apache\\.commons\\.lang3\\..*");
        includeClass.add("^org\\.springframework\\..*");
//        includeClass.add("^java\\..*");

        ManagerClassLoader urlClassLoader = new ManagerClassLoader(new URL[]{builderUrl(file)}, new ManagerClassLoader.Routing(
                ClassLoaderTest.class.getClassLoader(),
                includeClass.toArray(includeClass.toArray(new String[0]))));
        AnnotationConfigApplicationContext pluginApplicationContext = new AnnotationConfigApplicationContext();
        pluginApplicationContext.setClassLoader(urlClassLoader);
        pluginApplicationContext.scan("com.sandbox.application.plugin");
        pluginApplicationContext.refresh();

        Trace bean = pluginApplicationContext.getBean(Trace.class);
        String id = bean.getId();
        System.out.println(">>>>> 执行 :: " + id);
        return pluginApplicationContext;
    }

这里的话就是遇到这些类的话使用主加载器去加载,否则使用自己的加载器。

然后联想到关键引用图中有一个,这里有点运气的因素。

image.png

这个属于主加载器也有的,但是没在转发中声明路径,然后加入了这个路径。

//加上这个
includeClass.add("^com\\.lkx\\..*"); //todo 原来如此

然后按照上述步骤重新测试,发现com.lkx.jvm.sandbox.core.classloader.ManagerClassLoader#finalize的方法被回调了,类也被回收了。

此时,脑瓜子依然嗡嗡作响~。。。


给个解释吧?我也不知道啊!睡服不了自己啊?

强装镇定...

按照正常来讲,A和B是两个不同的加载器,B负责加载插件范围内的实例,比如lang3的工具类,这个是不会和A的工具类起冲突的,因为是各自独立的。那么InterfaceProxyUtils这个工具类为什么不同呢?即便A和B都依赖这个工具类,也是各自独立的。为什么会有引用关系呢?

知道了结果,这个时候我们开始反推过程。

然后开始捣鼓JProfile,发现有个功能可以从实例一直往上查找直到GC ROOT ! 绝了~

  • 选中一个应该被回收的类
image.png

image.png

从这个路径中可以发现挺多问题的,原来这个类是被Spring持有的。从之前的图也能看出端倪..


image.png

4. 胡说八道

为什么Spring会持有呢?首先我们加载插件包的时候是用的Spring的scan方式扫描的包,但是我们先看一下入口类 AttributeMethods

// 省略大部分源码
final class AttributeMethods {
    // 静态缓存类,而且还是全局的
    private static final Map, AttributeMethods> cache =
            new ConcurrentReferenceHashMap<>();
    
    // 重点看是哪里调用了这个静态方法
    static AttributeMethods forAnnotationType(@Nullable Class annotationType) {
        if (annotationType == null) {
            return NONE;
        }
        return cache.computeIfAbsent(annotationType, AttributeMethods::compute);
    }
}

原来这里面是有一个保存属性结构的全局缓存工具类,一旦加载插件包中发现属性注解的时候都会先缓存起来。

调用入口在org.springframework.core.annotation.AnnotationTypeMapping#AnnotationTypeMapping中调用了AttributeMethods._forAnnotationType_(annotationType);

我们插件包中确实有一个类注解缓存比如:

interface IHttpServletRequest {

    @InterfaceProxyUtils.ProxyMethod(name = "getRemoteAddr")
    String getRemoteAddress();

}

Spring在解析的时候会把一些结构性的东西保存下来。

这个时候相当于B加载器的实例对象引用被A加载器的实例应用持有了,所以一直回收不了。但是如果在ManagerClassLoader声明这个类的路径就是由A加载,B去A里面找的话,就能够被回收。

image.png

以上兜兜转转终于定位到了,也是对JProfile有了更深一步的了解。
很多时候当你知识面不够广的时候,可以换一种思路去验证:

  • 比如排除法,先把复杂的东西简单化,一步一步验证。
  • 在无意中得到解决方法的时候,你不知道为什么会这样?
  • 此时再通过结果反推过程,得到最终的原因。

如果此时你正在观看这篇文章,不要纠结能不能解决你目前的问题,排查思路和工具的使用能够让你让你多一种解决方案。

不太喜欢贴大量代码,影响阅读,所以不要纠结代码。

你可能感兴趣的:(排查实战之ClassLoader动态加载插件无法回收引用排查)