JDBC和Tomcat打破双亲委派模型是为满足现实刚性需求：JDBC通过线程上下文类加载器解决启动类加载器需加载应用级驱动的矛盾；Tomcat通过WebAppClassLoader实现应用隔离与版本共存，二者均在可控边界内策略性绕过委派而非破坏安全内核。
双亲委派模型本身是安全且严谨的设计，但现实场景中存在两类刚性需求：一类是“上层系统需要加载下层实现”，另一类是“多个应用需隔离又共存”。JDBC 和 Tomcat 正好分别代表这两种典型情况，它们打破委派不是为了绕开规则，而是让规则在更复杂的运行环境中依然成立。
JDBC 必须打破委派：接口与实现跨层级分离
java.sql.Driver 接口由启动类加载器（Bootstrap）从 rt.jar 加载，而 MySQL、PostgreSQL 等驱动实现类却在应用 classpath 下，归应用类加载器（AppClassLoader）管辖。按标准双亲委派，Bootstrap 无法委托子加载器去加载自己“看不见”的类——它只查 $JAVA_HOME/jre/lib，根本不会扫描项目 lib 目录。
解决方式很明确：
- DriverManager 初始化时，不依赖自身类加载器，而是读取当前线程的上下文类加载器（Thread Context ClassLoader），默认就是 AppClassLoader
- 通过 ServiceLoader.load(Driver.class) 触发加载，底层调用 Class.forName(driverClassName, false, contextClassLoader)
- 这样，虽由 Bootstrap 加载的 DriverManager 发起请求，实际执行加载的是应用类加载器，成功拿到 com.mysql.cj.jdbc.Driver 等实现类
Tomcat 打破委派：为应用隔离与热部署让路
Tomcat 作为 Web 容器，要同时运行多个 Web 应用（如 A.war 和 B.war），每个应用可能含同名类（比如 commons-logging）、不同版本的 Spring，甚至自定义的 javax.servlet.http.HttpServlet 子类。若严格走双亲委派，所有应用共享 AppClassLoader，就会相互污染、版本冲突、无法卸载。
它的解决方案是重构类加载器树：
- 新增 WebAppClassLoader，每个应用独享一个实例，优先用自己的目录（WEB-INF/classes + WEB-INF/lib）加载类
- 对 Java 核心类（java.*、javax.* 中非 Servlet 规范部分）仍向上委派给 SharedClassLoader 或 CommonClassLoader
- 对 Servlet API（javax.servlet.*）等容器契约类，则由 CatalinaClassLoader 统一提供，确保容器与应用之间类型兼容
- 这种“局部倒置”不是全盘否定委派，而是按包名策略性绕过：遇到业务类先自己加载，遇到基础类再向上交
破坏不等于随意，关键在可控边界
两者都未放弃双亲委派的精神内核，只是调整了“谁该负责哪部分”的责任划分：
- JDBC 借助线程上下文类加载器，在调用链中临时切换加载主体，保持接口稳定的同时开放实现插拔
- Tomcat 用分层+白名单机制（如 useSystemClassLoaderForPool=false、delegate=false 配置），把委派逻辑从“无条件向上”变成“按需向上”
- 真正危险的是完全自定义 loadClass() 并跳过父加载器检查——这会绕开所有安全校验；而 JDBC 和 Tomcat 的破坏都在受控范围内，有明确目的和回退路径
