双亲委派被破坏的典型场景有四类：1. 线程上下文类加载器（TCCL）用于SPI加载；2. 模块化容器如OSGi实现类隔离；3. JDK自身对动态代理、Lambda等的特殊处理；4. 用户自定义ClassLoader主动绕过。
双亲委派被破坏的典型场景
Java 的双亲委派模型不是铁律，而是一种设计约定。在实际开发和 JDK 自身演进中，有几种明确且合理的“破坏”方式，它们不是 bug，而是为了解决特定问题而做的主动绕过。
1. 线程上下文类加载器（TCCL）——打破委派链的主动选择
这是最常见、最标准的破坏方式。当高层框架（如 JNDI、JDBC、JAXP）需要加载由应用开发者提供的实现类时，它无法通过当前类加载器（比如 Bootstrap 或 Extension 类加载器）去加载应用目录下的类——因为双亲委派会一路向上，最终失败。
解决办法是：让线程绑定一个能加载业务类的类加载器（通常是 AppClassLoader），框架内部显式调用 Thread.currentThread().getContextClassLoader() 来加载 SPI 实现。
- JDBC 驱动注册就是经典例子：
DriverManager在 Bootstrap 类加载器中，但它通过 TCCL 去加载com.mysql.cj.jdbc.Driver这类位于 classpath 下的驱动类 - Tomcat 为每个 Web 应用设置独立的
WebAppClassLoader，并将其设为线程上下文类加载器，确保 Servlet 能加载本应用的类
2. 热部署与模块化容器——自定义类加载隔离逻辑
OSGi、Spring Boot DevTools、JRebel 等工具为了实现模块热替换或类隔离，会构造多层级、网状甚至并行的类加载关系，完全不遵循“父优先”原则。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- OSGi 中每个 Bundle 拥有独立的类加载器，依赖通过 Import-Package 显式声明，查找类时先查自己 bundle，再查导入包，最后才可能委托给父加载器
- 这类加载器通常重写
loadClass()方法，跳过super.loadClass()，直接从本地资源或缓存加载
3. JDK 自身的“例外”——基础类型与运行时动态生成
部分核心类虽在启动阶段加载，但其行为本身绕过了标准流程：
-
java.lang.ClassLoader是由 Bootstrap 加载器加载的，但它自身是一个 Java 类，其defineClass()等方法允许子类直接定义类字节码，无需委派 - 动态代理（
Proxy.newProxyInstance()）、Lambda 表达式生成的类，由sun.misc.Launcher$AppClassLoader（或自定义类加载器）直接defineClass，不经过 findClass → parent.loadClass 流程 - String.intern() 缓存的字符串对象不涉及类加载，但常被误认为“破坏委派”，其实无关
4. 用户主动绕过——慎用但可行的技术手段
开发者可通过继承 ClassLoader 并重写 loadClass(String name, boolean resolve)，跳过 if (parent != null) parent.loadClass(...) 步骤，实现“子优先”或“并行加载”等策略。
但要注意：
- 不要在重写中漏掉对
findBootstrapClassOrNull()的调用，否则可能无法加载java.*类 - 避免重复定义同一个类（不同类加载器定义的同名类视为不同类型），否则引发
ClassCastException - 破坏委派后需自行保障类可见性、版本兼容和卸载安全
基本上就这些。破坏双亲委派不是错误，而是权衡之后的必要设计。关键是理解“为什么绕过”，而不是“能不能绕过”。
