如何隔离自定义类加载器加载的Fat Jar依赖，避免与主应用产生类版本冲突

现有实现的隔离性不足，根源是自定义JarByteClassloader默认遵循JVM双亲委派机制，会优先将类加载请求委派给父加载器（即主应用所在的类加载器）。哪怕自定义加载器的内存Jar字节流中包含28版本的Guava类，只要父加载器已经加载了30.1.1版本的Guava，就会直接返回父加载器已加载的类，完全跳过自定义加载器自身的字节读取逻辑，最终导致Fat Jar误用主应用的依赖版本，触发类冲突。

1. 重写类加载委派规则，明确加载优先级边界 #

这是实现完全隔离的核心，不能沿用默认的双亲委派顺序，需要按以下规则调整类加载流程：

• 定义两类类的加载边界：
  • 优先委派父加载器加载的白名单类：仅包含JDK核心类（包路径以java.、javax.、jdk.开头的类）、主应用与Fat Jar约定的共享类（比如主应用定义的JarEntryObject接口、通用交互数据模型等需要双向关联的类）
  • 完全由当前JarByteClassloader加载的类：其余所有类（包括Fat Jar打包的全部第三方依赖，比如示例中28版本的Guava、其他业务依赖），全部由当前加载器自行从内存Jar字节流中读取、定义、加载，绝不委派给父加载器

  特别注意：和Fat Jar做交互的入口接口、数据模型类必须加入白名单，否则会出现不同类加载器加载同名类不兼容的ClassCastException。

• 重写loadClass方法的执行顺序，替换默认的双亲委派逻辑：
  1. 先检查当前类加载器的已加载类缓存，若目标类已缓存则直接返回
  2. 判断目标类是否属于白名单范畴，若是则调用父加载器的loadClass方法加载
  3. 不属于白名单的类，直接调用当前加载器的findClass逻辑，从内存中的Fat Jar字节数组里读取对应class的字节内容，通过defineClass生成Class对象后存入自身缓存

对应的核心重写逻辑参考代码：

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 1. 命中当前加载器的已加载类缓存直接返回
    Class<?> c = findLoadedClass(name);
    if (c != null) {
        return c;
    }
    // 2. 白名单类走父加载委派逻辑
    if (isParentDelegationClass(name)) {
        return super.loadClass(name, resolve);
    }
    // 3. 非白名单类优先从当前加载器的内存Jar中读取加载
    try {
        return findClass(name);
    } catch (ClassNotFoundException e) {
        // 兜底：当前Jar中找不到的类再走父加载委派，兼容未打包的公共类
        return super.loadClass(name, resolve);
    }
}

2. 补充隔离边界的防泄漏、防错配机制 #

• 增加加载校验逻辑：加载Fat Jar自带的依赖类时，若发现目标类已经被父加载器加载，直接抛出明确的类冲突异常，提前定位版本错配问题，避免运行时出现诡异的方法不存在、类转换异常。
• 清理上下文类加载器的关联：每次执行完Jar内的方法调用后，要将当前线程的上下文类加载器恢复为调用前的原始值，避免内存中的Jar字节流、加载的Class对象因为被线程上下文持有而无法被GC回收，引发类加载器泄漏。

3. 场景化验证隔离效果 #

针对Guava版本冲突的典型场景，加载完成后增加校验：

• 调用com.google.common.base.Stopwatch.class.getClassLoader()，确认该类是由自定义JarByteClassloader加载，而不是主应用的类加载器加载
• 对比版本类的来源，确保Fat Jar运行时使用的Guava完全来自内存中加载的Jar包，和主应用的Guava版本无关联

内容的提问来源于stack exchange，提问作者quarks