类加载器自定义隔离实战：如何加载同名的类但在两个类加载器中通过 equals 判定为不同类型

Ja va类加载隔离的核心原理，简单来说就是一句话：一个类的“身份”在全JVM范围内，是由它的全限定名 + 加载它的类加载器实例共同决定的。两个类，哪怕字节码一模一样，包名类名完全一致，只要加载它们的类加载器实例不同，那么它们在JVM眼中就是两个完全不同的类型，彼此之间不能赋值、不能强转，静态变量也不共享。更直接一点：用equals判等，返回false；用==比引用，也是false。

所以，“能不能加载同名类”根本就不是问题。真正值得搞清楚的是：JVM到底怎么判定两个类“相同”或“不同”？

类唯一性判定逻辑，必须透彻

Ja va规范里写得很清楚：一个类在JVM中的运行时身份，由两个要素唯一锁定——全限定类名（比如com.example.Hello）和加载它的类加载器实例（注意，是对象，不是类本身）。

这意味着什么？

• loaderA.loadClass("com.example.Hello") 和 loaderB.loadClass("com.example.Hello") 返回的两个 Class 对象，即便字节码完全一致，class1 == class2 的结果必然是 false。
• 它们各自 newInstance() 出来的对象，obj1.getClass() == obj2.getClass() 同样是 false。
• 调用 obj1.equals(obj2) 呢？如果类没重写 equals，默认走 Object.equals，比较的是引用，结果肯定是 false。就算重写了，通常也会先判断 getClass() 是否相同——这一关就过不去，所以还是会返回 false。

这个逻辑是整个类加载隔离的根基，不理解它，后面所有实践都是空中楼阁。

实战：两个 URLClassLoader 加载同名类

验证这个机制其实很简单，甚至不需要写自定义类加载器，直接用现成的 URLClassLoader 就行。

假设我们准备了两个目录：/tmp/plugin-a/ 和 /tmp/plugin-b/，各自放一份编译好的 Hello.class（内容完全一样都没关系）。

• 创建加载器A：new URLClassLoader(new URL[]{new File("/tmp/plugin-a/").toURI().toURL()})
• 创建加载器B：new URLClassLoader(new URL[]{new File("/tmp/plugin-b/").toURI().toURL()})
• 分别加载：Class c1 = loaderA.loadClass("Hello");，Class c2 = loaderB.loadClass("Hello");
• 跑一下验证：System.out.println(c1 == c2); // 输出 false，System.out.println(c1.getClassLoader() == c2.getClassLoader()); // 也是 false

这时候，再用 c1.getDeclaredConstructor().newInstance() 和 c2.getDeclaredConstructor().newInstance() 分别创建两个对象，它们的 getClass() 已经不同了，那么无论是 equals 还是任何类型安全的比较，都无法让它们互通。

想真正隔离，得打破双亲委派

这里有一个容易踩的坑：如果直接用默认的加载器行为——比如继承了 URLClassLoader 但没重写 loadClass——那么某些类可能被父加载器（比如 AppClassLoader）提前加载了。结果就是，表面上看用了两个不同的加载器实例，实际上共用的还是同一个 Class 对象，隔离根本不存在。

要确保隔离生效，必须主动控制加载路径：

• 推荐做法：用 URLClassLoader(URL[], ClassLoader parent) 这个构造函数，显式传入 null 作为 parent。也就是说，不让它委托给系统类加载器。或者自己写一个空的、无父的自定义加载器。
• 需要避免的：别依赖线程上下文类加载器（Thread.currentThread().getContextClassLoader()）的默认值。它通常是 AppClassLoader，会破坏你精心设计的隔离边界。
• 验证手段：打印每个 Class 的 getClassLoader()，确认它们确实来自你创建的那两个不同实例。这是最直接的检查方法。

equals 判定为不同类型？这不仅仅是 equals 的问题

很多人容易在这里产生误解，觉得“只要我重写一下 equals 方法，不就能让两个不同加载器加载的对象判等了吗？”答案是否定的。因为问题根本不在 equals 方法本身，而在于 JVM 底层的类型系统已经把这两个类划入了互不兼容的类型阵营。

举个例子：

• 方法签名匹配失败：比如你定义了一个方法 void process(Hello h)，如果传进来的是一个由 loaderB 加载的 Hello 实例，编译就能报错，运行时更是直接 NoSuchMethodError。
• 强制转型失败：(Hello) obj 会抛出 ClassCastException，因为运行时的真实类型和你期望的类型不匹配。
• equals 的实现：哪怕是 Apache Commons Lang 的 EqualsBuilder，内部也会先做 getClass() == other.getClass() 这一关。这一关过不去，后面再怎么重写都是白搭。

所以，结论很明确：“equals 判定为不同类型”这句话，本质上描述的是 JVM 类型系统的刚性约束。它不是业务逻辑能绕过去的坎，而是类加载隔离机制在设计层面的必然结果。理解了这一点，才算真正掌握了 Ja va 类加载隔离的精髓。