双亲委派模型是java类加载器协作的核心机制，即子加载器收到请求时先委托父加载器（直至bootstrap），仅当父加载器无法加载时才自行加载；该机制保障了核心类安全、类唯一性（由“类名+加载器”共同标识）及资源隔离，同时支持通过重写loadclass等策略在插件、热部署等场景中受控打破委派以实现模块化协作。
Java 类加载器之间的协作，核心是“委托”与“隔离”的平衡——不是所有加载器都直接干活，而是按层级分工；也不是完全隔绝，而是在可控范围内共享基础能力。
双亲委派模型是协作的基础机制
当一个类加载器收到加载请求时，它不会立刻自己去加载，而是先交给父加载器尝试。这个流程逐级向上，直到启动类加载器（Bootstrap）。只有父加载器明确无法找到该类时，当前加载器才真正执行加载逻辑。
- 启动类加载器负责
java.*等核心类（如String、Object），保证底层安全和一致性 - 扩展类加载器加载
lib/ext下的类，提供标准扩展支持 - 应用程序类加载器（AppClassLoader）加载 classpath 中的用户代码，是绝大多数自定义加载器的默认父加载器
这种链式委托避免了重复加载，也防止低层级加载器篡改核心类——比如你无法用自己的 java.lang.String 替换 JVM 自带的版本。
类唯一性由“类名 + 加载器实例”共同决定
两个不同加载器加载的同名类，在 JVM 看来是完全独立的类型。它们之间不能强转、不能共用静态变量、也不能互相赋值。
- 例如：用
URLClassLoader分别加载plugin-a.jar和plugin-b.jar中的com.example.Service，得到的两个Class对象==为false - 关键点在于：JVM 内部用
(全限定类名, ClassLoader 实例)作为类的唯一标识键 - 这意味着协作的前提是明确“谁加载了什么”，否则容易出现
ClassCastException或NoSuchMethodError
打破委派实现受控隔离与协作
在插件系统、热部署或多租户场景中，需要让模块间类互不干扰，但又得复用基础类（如日志、JSON 工具）。这时需有策略地打破默认委派链。
- 重写
loadClass(String, boolean)方法，优先调用findClass()而非直接委派 - 对需要共享的类（如
org.slf4j.*、java.util.*）仍走父委派，确保统一版本 - 对模块专属类（如
com.myapp.plugin.XxxService）由当前加载器直接加载，形成隔离层 - 避免将两个自定义加载器设为彼此的父加载器，也慎用
null作为父加载器（会导致连Object都找不到）
跨加载器协作需借助接口或反射
不同加载器加载的类天然无法直接引用，但可通过设计手段打通协作路径。
- 把交互契约定义在父加载器能加载的接口中（例如放在主程序 classpath 下），双方都实现它
- 使用反射调用方法：获取目标类的
Class对象后，通过getDeclaredMethod和invoke执行逻辑 - 服务注册/发现机制：由统一上下文（如 OSGi 的 BundleContext 或 Spring 的 ApplicationContext）管理生命周期和依赖关系
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
