破坏双亲委派机制是为解决JDBC驱动加载、Web应用隔离、模块化与热部署等真实问题而做的合理设计；核心在于理解动因、控制委派边界、避免类冲突与加载异常。
破坏双亲委派机制不是 bug，而是为解决真实工程问题做出的合理设计选择。核心在于：当标准“父优先”逻辑无法满足需求时，必须主动调整类加载行为。关键不在于能否打破，而在于是否理解动因、控制边界、避免副作用。
JDBC 驱动加载：父类加载器无法访问子类路径
java.sql.Driver 接口由 Bootstrap 加载器加载（在 rt.jar 中），但具体实现类（如 com.mysql.cj.jdbc.Driver）在应用 classpath 下，只能由 AppClassLoader 加载。双亲委派链无法让 Bootstrap 去加载用户 jar 中的类。
应对方式是使用线程上下文类加载器（TCCL）：
- 应用启动时，框架（如 Spring、Tomcat）会显式调用 Thread.currentThread().setContextClassLoader(AppClassLoader)
- JDK 的 ServiceLoader.load(Driver.class) 内部会读取 TCCL，从而用应用类加载器加载驱动实现
- 开发者无需重写 loadClass，只需确保 TCCL 设置正确；排查时可打印 Thread.currentThread().getContextClassLoader() 验证
Web 应用隔离：多个应用共存需版本互不干扰
同一 Tomcat 部署多个 WAR 包，若共用 Application ClassLoader，不同版本的 Spring、Logback 就会冲突。标准委派模型会让所有应用共享顶层加载器，失去隔离性。
立即学习“Java免费学习笔记（深入）”；
应对方式是实现“本地优先”的 WebAppClassLoader：
- 重写 loadClass(String name, boolean resolve)，跳过 super.loadClass() 调用
- 先尝试从 WEB-INF/classes 和 WEB-INF/lib 加载
- 仅对 javax.servlet.*、java.* 等白名单类才委派给 SharedClassLoader 或 Bootstrap
- 加载失败后，再 fallback 到父加载器（形成“子→父→子”弹性链）
模块化与热部署：需要精细控制依赖边界
OSGi 要求 Bundle 级别可见性控制，JRebel 需在运行时替换类定义——两者都无法依赖扁平、单向的父子委托链。
应对方式是构建非层级类加载关系：
- OSGi 中每个 Bundle 拥有独立 ClassLoader，查找顺序为：本 Bundle → Import-Package 声明的依赖 → 父加载器
- JRebel 使用自定义 URLClassLoader，重写 loadClass 后直接从监控目录读取新字节码，完全跳过委派
- Spring Boot DevTools 采用双 ClassLoader 结构：BaseClassLoader 加载不变的第三方库，RestartClassLoader 加载变动的应用类，重启时只丢弃后者
排查与工程建议
破坏委派易引发 ClassNotFoundException、NoClassDefFoundError 或 ClassCastException（同一类被不同加载器加载两次）。应对要点：
- 优先使用 TCCL 而非自定义 loadClass，降低侵入性
- 自定义 ClassLoader 时，明确声明哪些包必须委派（如 java.、javax.）、哪些必须本地加载（如应用包）
- 调试时打印 clazz.getClassLoader() 和 Thread.currentThread().getContextClassLoader()，确认实际加载主体
- 避免切断 parent 为 null，除非你自行处理所有核心类（如 java.lang.*），否则极易触发 Bootstrap 类缺失异常
