java双亲委派模型是有目的、受控地绕过，而非破坏，核心是调整加载顺序或切换委托主体；需重写loadclass、保障classloader实例独立、接口与实现跨加载器解耦，并配套tccl、资源加载和内存泄漏防护。
Java 双亲委派模型不是被“破坏”，而是被**有目的、受控地绕过**，用于解决标准机制无法满足的现实需求，比如 Web 应用隔离、插件热加载、SPI 服务发现等。核心不在于删除委派逻辑，而在于**调整加载顺序或切换委托主体**。
重写 loadClass 是最直接的打破方式
双亲委派的逻辑全部封装在 ClassLoader.loadClass(String, boolean) 的默认实现中：先委派父类，失败后再调用自己的 findClass。要打破它，必须覆盖该方法，把顺序倒过来：
- 第一步：调用 findLoadedClass(name) 检查是否已加载，避免重复定义
- 第二步：根据业务规则（如包名前缀 com.myplugin.）直接调用 findClass(name) 尝试本地加载（从插件目录、JAR 或字节码缓存中读取）
- 第三步：仅当本地不匹配时，才显式调用 super.loadClass(name, resolve) 或 parent.loadClass(name) 委托上级
独立 ClassLoader 实例保障类隔离
类的唯一性由「全限定名 + 加载它的 ClassLoader 实例」共同决定。两个不同实例加载的 com.example.Service，JVM 视为完全无关的类型：
- 插件 A 使用 new PluginClassLoader("/plugins/a/", appClassLoader)
- 插件 B 使用 new PluginClassLoader("/plugins/b/", appClassLoader)
- 绝不能复用同一个加载器实例加载多个插件，否则类会互相污染、静态变量共享、转型失败
接口与实现必须跨加载器解耦
宿主与插件通信必须依赖“三方契约”——由宿主类加载器加载的纯接口：
- 宿主提供不含实现的接口 JAR，并确保它被 AppClassLoader 加载（例如放在 classpath）
- 插件编译期依赖该接口，但运行时不打包进插件 JAR；插件里的实现类由自己的 ClassLoader 加载
- 插件创建实现对象后，必须用宿主加载的接口类型接收，才能安全转型，否则抛 ClassCastException
配套机制缺一不可
只改 loadClass 远远不够，真实场景还需同步处理：
- 设置 TCCL：在插件执行线程中临时设为插件 ClassLoader，避免 JDBC 驱动、XML 解析器等 SPI 机制误用宿主加载器
- 重写资源加载：覆盖 getResource/getResources，确保 PluginClass.getResource("config.yml") 找到的是插件自身目录下的文件
- 防止内存泄漏：卸载插件时清空静态引用、关闭线程池、注销监听器；用弱引用持有回调对象，确保 ClassLoader 实例可被 GC 回收
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
