java类加载隔离的关键是精准控制委派边界：仅对指定包路径（如com.myapp.module.v2）本地加载，其余包括java.、javax.等一律向上委派；每个版本需独立classloader实例，jvm依据“类名+加载器实例”判定类型唯一性，并同步重写getresource等方法确保资源加载一致。
直接重写 loadClass 方法，但关键不是跳过委派，而是精准控制委派边界——只对明确归属的包路径（如 com.myapp.module.v2）走本地加载，其余一律向上委派，尤其是 java.*、javax.*、org.apache.catalina.* 等必须由父加载器加载，否则会触发 LinkageError 或 ClassCastException。
只在 loadClass 开头做包名白名单判断
所有“是否该自己加载”的决策必须集中在这里，不能分散到 findClass 或其他地方。例如：
- 若类名以
com.myapp.plugin.kafka.v2.开头，调用findClass尝试从插件目录加载 - 若类名以
java.、javax.、sun.、org.apache.catalina.开头，立即super.loadClass(name) - 其余情况也统一委派，避免漏判导致系统类被错误加载
findClass 只负责读字节码，不参与委派逻辑
它的职责非常单一：根据类名构造路径，读取 .class 文件字节流，然后调用 defineClass。不能在这里捕获 ClassNotFoundException 并尝试向上查找，也不能缓存或重试。
- 读不到文件就直接抛出
ClassNotFoundException - 绝不调用
super.findClass或任何父加载器方法 - 确保同一个类名被不同实例加载时，字节码来源隔离、路径独立
每个版本必须使用独立 ClassLoader 实例
定义一个 PluginClassLoader 类不等于实现隔离。真正起作用的是运行时创建的多个实例，比如：
new PluginClassLoader("/plugins/kafka-0.11/")new PluginClassLoader("/plugins/kafka-3.7/")
JVM 判定类是否相同，依据是「全限定类名 + 加载它的 ClassLoader 实例」。两个实例加载的 KafkaProducer，即使字节码完全一致，在 JVM 中也是不可转换、互不兼容的类型。
同步处理资源加载和线程上下文
仅改 loadClass 不够。插件代码中若调用 Class.getResource() 或依赖 Thread.currentThread().getContextClassLoader()，必须重写 getResource 和 getResources 方法，确保资源查找也走当前加载器路径。
- 避免因资源路径错配导致配置文件、XML 或注解扫描失败
- 显式设置线程上下文类加载器为当前插件加载器实例
- 尤其在 Spring 插件场景中，上下文类加载器不一致会导致 Bean 初始化异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
