Java类加载隔离的核心原理是类的唯一性由全限定名与加载器实例共同决定；即使字节码相同、类名一致，不同加载器加载的类也互不兼容，无法赋值、强转或共享静态变量。
可以做到，而且这是 Java 类加载隔离最基础也最关键的体现。关键不在于“能不能加载同名类”，而在于“JVM 怎么判定两个类是否相同”——它看的不是名字，而是全限定类名 + 加载它的类加载器实例。只要加载器实例不同，哪怕字节码一模一样、包名类名完全一致，JVM 就认为是两个独立的类，彼此不可赋值、不可强转、静态变量不共享，equals 和 == 都返回 false。
类唯一性判定逻辑必须清楚
Java 规范明确规定：一个类在 JVM 中的运行时身份由两个要素共同决定：
- 该类的全限定名（例如
com.example.Hello） - 加载它的 类加载器实例（不是类，是 new 出来的那个对象）
这意味着：
- loaderA.loadClass("com.example.Hello") 和 loaderB.loadClass("com.example.Hello") 返回的 Class> 对象，即使字节码完全相同，class1 == class2 为 false；
- 它们创建的实例，比如 obj1.getClass() == obj2.getClass() 同样为 false；
- 调用 obj1.equals(obj2) 时，若未重写 equals，默认走 Object.equals（即比较引用），结果必为 false；即使重写了，只要类型不同（obj1 是 Hello from loaderA，obj2 是 Hello from loaderB），instanceof 判定就失败，通常也会返回 false。
实战：用两个 URLClassLoader 加载同名类
无需写完整自定义类加载器，直接用 URLClassLoader 即可快速验证。假设你有两个目录 /tmp/plugin-a/ 和 /tmp/plugin-b/，各自放一份编译好的 Hello.class（内容可完全一样）：
- 创建 loaderA：`new URLClassLoader(new URL[]{new File("/tmp/plugin-a/").toURI().toURL()})`
- 创建 loaderB：`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）提前加载，导致看似用了两个 loader，实际仍共用同一个 Class 实例。要确保隔离，必须控制加载路径：
- 推荐方式：使用
URLClassLoader(URL[], ClassLoader parent)构造函数，显式传入null作为 parent（即不委托给系统加载器），或传入一个空的、无父的自定义 loader - 避免方式：不要依赖线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）默认值，它通常是 AppClassLoader，会干扰隔离 - 验证手段：打印每个
Class的getClassLoader()，确认它们确实来自你创建的两个不同实例
为什么 equals 判定为不同类型？不只是 equals 方法
这里容易误解的一点是：以为只要重写 equals 就能让两个不同加载器加载的对象“相等”。实际上，JVM 层面的类型系统已经将它们划分为互不兼容的类型：
- 方法签名匹配失败：比如
void process(Hello h)，传入 loaderB 加载的Hello实例会编译报错或NoSuchMethodError - 强制转型失败：
(Hello) obj抛ClassCastException，因为运行时类型不匹配 -
equals的常规实现（如 Apache Commons Lang 的EqualsBuilder）内部会先做getClass() == other.getClass()检查，这一关就过不去
所以，“equals 判定为不同类型”本质是 JVM 类型系统的刚性约束，不是业务逻辑能绕过的。
