双亲委派模型是为安全与一致性设计的默认策略，其本质是子加载器先委托父加载、父失败后才自行加载；但Web隔离、SPI扩展、热部署等场景需有节制地破坏，如Tomcat翻转查找优先级、SPI通过TCCL实现逆向委托、自定义加载器须重写loadClass并明确范围。
双亲委派模型不是铁律，而是为安全与一致性设计的默认策略；真正理解它，关键在于看清“何时必须打破”以及“怎么破才可控”。破坏不是为了绕开规则，而是让类加载行为贴合真实场景——比如 Web 应用隔离、SPI 扩展、热部署等。
双亲委派的本质逻辑
标准流程是：子加载器收到请求 → 先委托父加载器尝试 → 父无法加载（抛 ClassNotFoundException）→ 子才自己加载。这个顺序保障了 java.*、javax.* 等核心类由 Bootstrap 加载，避免被篡改或重复定义。
但它的硬约束在复杂运行环境中会出问题：
- 两个应用依赖不同版本的 Spring，按双亲委派会被顶层统一加载一份，导致方法缺失或类型不匹配
- JDBC 驱动在 classpath，而 DriverManager 在 rt.jar（Bootstrap 加载），后者需加载前者，但 Bootstrap 无法反向委托给应用类加载器
- 热更新时需要卸载旧类、加载新类，而默认委派链下类无法被卸载（父加载器持有引用）
Tomcat 的“有节制破坏”
WebAppClassLoader 是典型实践：它重写了 loadClass 方法，把“先委派”改成“先自查”。
- 检查类名是否以 java.、javax.、sun. 开头 → 强制走父加载器（保安全）
- 检查是否已在 /WEB-INF/classes 或 /WEB-INF/lib 中 → 是则调用 findClass 自己加载
- 仅当 findClass 抛出异常，才调用父加载器的 loadClass
这种调整不破坏整体结构，只是翻转了 Web 层的查找优先级。SharedClassLoader 和 CommonClassLoader 仍严格遵循委派，确保 servlet-api.jar 等规范类全局唯一。
SPI 机制中的逆向委派
JDK 的 java.util.ServiceLoader 使用线程上下文类加载器（TCCL）实现“父加载器调用子加载器”的逆向加载：
- DriverManager 由 Bootstrap 加载，但它内部通过 Thread.currentThread().getContextClassLoader() 获取当前应用的类加载器
- 再用该加载器去加载 META-INF/services/java.sql.Driver 中声明的实现类
- 这样就能让 rt.jar 中的代码，安全地加载用户 classpath 下的驱动
这是 JVM 官方认可的破坏方式，依赖的是显式切换加载器上下文，而非覆盖 loadClass。
自定义类加载器的正确姿势
若要实现插件隔离或热替换，必须同时满足三点：
- 重写 loadClass（不能只改 findClass，否则请求根本到不了你）
- 明确划分加载范围（如只加载 plugin/lib/ 下 JAR，跳过 java.* 和已知共享包）
- 确保类卸载可行：避免静态引用、使用弱引用缓存、配合 ClassLoader 实例生命周期管理
例如，一个插件加载器可约定：所有插件类加前缀 com.example.plugin.，加载时先拦截该前缀，查不到再委派；而第三方库如 slf4j-api 则直接交给父加载器，避免冲突。
