双亲委派机制被破坏是为解决特定问题的合理设计妥协，主要出现在spi服务加载（如jdbc驱动）、web容器应用隔离（如tomcat）、模块化与热部署（如osgi、jrebel）及jdk内部特殊逻辑（如动态代理、lambda）四类场景。
Java 中双亲委派机制被破坏不是错误，而是为解决特定问题而做的合理设计妥协。它主要出现在四类典型场景中，每种都对应明确的技术动因和实现方式。
SPI 服务加载（如 JDBC 驱动注册）
接口定义在核心库（如 java.sql.Driver），由 Bootstrap 类加载器加载；但具体实现（如 com.mysql.cj.jdbc.Driver）在应用 classpath 下，必须由 Application ClassLoader 加载。双亲委派无法让父加载器去加载子路径的类，因此必须绕过。
- 关键机制是线程上下文类加载器（TCCL）：
ServiceLoader.load(Driver.class)内部会调用Thread.currentThread().getContextClassLoader()，显式使用应用类加载器 - Tomcat、Spring 等框架在启动时会主动设置 TCCL，确保 JDBC、JNDI、JAXP 等标准服务能正确发现并加载业务实现
Web 容器中的应用隔离（如 Tomcat）
同一服务器部署多个 Web 应用，若共用 Application ClassLoader，不同版本的 Spring、Logback 就会冲突。Tomcat 为此为每个应用创建独立的 WebAppClassLoader，并打破委派顺序。
- 默认不先委派给父加载器，而是优先从当前应用的
WEB-INF/classes和WEB-INF/lib加载 - 仅当本地找不到时，才按需委派（例如加载
javax.servlet.*时委派给共享的CommonClassLoader） - 这种“子优先”策略实现了类级别的隔离，避免版本污染
模块化与热部署系统（如 OSGi、JRebel）
OSGi 要求 Bundle 之间精确控制依赖边界，不能简单依赖“父优先”的扁平委托链；JRebel 则需在不重启 JVM 的前提下替换类定义。
- OSGi 中每个 Bundle 拥有独立类加载器，查找类时先查本 Bundle，再查 Import-Package 声明的依赖，最后才考虑父加载器
- JRebel 自定义 URLClassLoader，重写
loadClass，跳过委派，直接从监控目录重新加载字节码 - 这类方案本质是构建网状或并行类加载关系，而非单向层级链
JDK 内部特殊逻辑（如动态代理、Lambda）
某些 JDK 功能需要在运行时生成字节码并立即加载，而生成类往往依赖当前业务类的类型信息，必须与业务类使用同一个类加载器。
-
Proxy.newProxyInstance显式接收ClassLoader参数，生成的代理类由该加载器 define，不走委派 - Lambda 表达式编译后生成的隐藏类（
xxx$$Lambda$1），由Unsafe.defineAnonymousClass创建，加载器与宿主类一致 - 这些属于 JVM 层面的“特例处理”，不在用户代码中体现，但确实绕过了标准委派流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
