java类加载器通过为每个版本创建独立classloader实例实现多版本隔离，重写loadclass()切断委派链，接口由appclassloader统一加载，资源与上下文需同步管控。
Java 类加载器实现多版本代码隔离与加载，核心在于利用“类的唯一性由类名 + 加载器实例共同决定”这一机制，通过自定义类加载器打破双亲委派，并严格控制加载路径和委托边界。
每个版本独占一个 ClassLoader 实例
不能只写一个自定义类加载器类就完事。必须为不同版本创建独立的加载器实例，比如：
-
Spring 5.3 使用
new PluginClassLoader("/plugins/spring-5.3/") -
Spring 6.1 使用
new PluginClassLoader("/plugins/spring-6.1/")
这样，即使两个加载器都尝试加载 org.springframework.context.ApplicationContext，JVM 也会生成两个互不可见的 Class 对象——它们无法强转、无法 instanceof 判定、静态变量完全隔离。
重写 loadClass() 主动切断委派链
仅重写 findClass() 不够，必须覆盖 loadClass(String name, boolean resolve) 才能绕过默认流程：
- 先调用
findLoadedClass(name)查缓存 - 若未加载，直接调用
findClass(name)从本版本路径加载字节码 - 仅当
findClass抛出ClassNotFoundException时，才调用super.loadClass()委托父加载器（用于加载java.*、javax.*等基础类）
这样既保证了业务类（如 Spring）的隔离，又避免了重复加载 JDK 类导致异常。
接口与实现必须物理分离
跨加载器传参或调用会失败，因为 v1.Loader 加载的 Request 和 v2.Loader 加载的 Handler 属于不同命名空间：
- 把
Operator、Result等契约接口放在主工程，由系统类加载器（AppClassLoader）加载 - 各版本插件只实现这些接口，内部使用自己版本的依赖（如 kafka-clients-0.10.2.2.jar）
- 主程序通过反射创建插件实例，持有类型为接口的引用，参数/返回值只用接口或 JDK 基础类型（
String、Map、byte[]）
配套资源与上下文需同步管控
类加载不是孤立行为，还需协调配套机制：
- 重写
getResource()和getResources()，确保配置文件、META-INF/services 等资源也走本加载器路径 - 在执行插件逻辑前，临时设置线程上下文类加载器（
Thread.currentThread().setContextClassLoader(loader)），避免框架（如 Log4j、JDBC DriverManager）误用 AppClassLoader - 避免在 static 块或初始化阶段触发跨版本类引用，否则会提前触发委派，破坏隔离
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
