双亲委派机制被破坏是为解决实际工程问题的合理设计让步，主要出现在spi反向加载（如jdbc）、应用类隔离（如tomcat）和动态策略切换三类场景，典型手段包括重写loadclass、使用线程上下文类加载器及自定义类加载器。
双亲委派机制被破坏，并非 bug，而是为解决实际工程问题做出的合理设计让步。它主要出现在三类典型场景中：需要父加载器调用子加载器加载类、需要应用间类隔离、或需绕过默认委托链实现动态策略切换。
JDBC 驱动通过 SPI 机制打破委派
DriverManager 类由 Bootstrap 类加载器加载（属于核心 API），而具体驱动如 com.mysql.cj.jdbc.Driver 通常放在应用 classpath 下，由 Application ClassLoader 加载。按双亲委派，Bootstrap 无法看到子加载器加载的类——这就导致 DriverManager 找不到驱动。
解决方案是引入线程上下文类加载器（Context Class Loader）：
- DriverManager 在静态初始化时，会主动获取当前线程的 contextClassLoader（通常是 Application ClassLoader）
- 再通过 ServiceLoader.load(Driver.class, cl) 显式用该加载器去扫描
META-INF/services/java.sql.Driver - 这样就实现了“父加载器委托子加载器加载”，方向与双亲委派相反
Tomcat 为 Web 应用隔离而定制类加载器
一个 Tomcat 实例常运行多个 Web 应用（如 A.war 和 B.war），它们可能依赖不同版本的 commons-lang 或 log4j。若全走双亲委派，所有应用共享 Application ClassLoader，就会冲突。
Tomcat 的做法是：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 为每个 WebApp 创建独立的 WebAppClassLoader，父加载器设为 SharedClassLoader（而非系统类加载器）
- 重写
loadClass()：先尝试自己加载/WEB-INF/classes和/WEB-INF/lib/中的类 - 仅当加载失败且非系统类（如 java.*、javax.*）时，才委派给父加载器
- 这形成“自底向上查找 + 有选择委派”，本质是反向委派
线程上下文类加载器（TCCL）显式绕过委派链
这是最轻量也最常用的破坏方式，不修改类加载器结构，只在运行时临时指定加载器。
典型用途包括：
- 框架（如 JNDI、JAX-WS、Thread.currentThread().setContextClassLoader(...)）需加载用户提供的 SPI 实现
- 第三方库（如 Logback、SLF4J）在初始化时读取配置并加载用户扩展类
- 开发者可通过
Thread.currentThread().getContextClassLoader()获取当前线程绑定的加载器，用于资源定位或类加载
自定义类加载器主动重写 loadClass 方法
当需要完全控制加载顺序（比如热替换、加密解密、沙箱隔离），开发者可继承 ClassLoader 并重写 loadClass(String, boolean)。
关键点在于：
- 不调用
super.loadClass()，跳过默认委派逻辑 - 直接调用
findClass()尝试从特定路径、网络或内存加载字节码 - 常见于热部署工具（如 Spring Boot DevTools）、插件化系统（如 IDE 插件平台）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
