打破双亲委派是为了满足类隔离、热更新和跨层级服务加载三类刚性需求；osgi通过bundle模块化契约控制可见性，tomcat以web应用为单位反转加载顺序，线程上下文类加载器则在调用链中动态注入子加载器能力。
打破双亲委派不是为了绕开规范，而是为了解决真实场景中类隔离、热更新和跨层级服务加载这三类刚性需求。OSGi 和 Tomcat 是两种典型实现路径：前者通过模块化契约定义精细的类可见性边界，后者以 Web 应用为单位构建轻量级隔离沙箱。它们都主动重写 loadClass，但控制变量的侧重点不同。
OSGi 的模块化加载：以 Bundle 为单位控制导出/导入策略
OSGi 不依赖父子委托链，而是构建“平级委托 + 显式依赖声明”的模型。每个 Bundle（模块）拥有独立 ClassLoader，并通过 Import-Package 和 Export-Package 清单属性声明类的可见范围。
- 类加载优先从本 Bundle 的
Bundle-ClassPath查找，不自动向上委托 - 若需使用其他 Bundle 的类，必须在
MANIFEST.MF中明确Import-Package: org.slf4j，且目标 Bundle 已导出该包 - 同一接口的多个实现可共存（如两个 Bundle 各自提供
DataSourceFactory），由服务注册中心按条件匹配，避免版本冲突 - Bundle 可动态
start/stop/uninstall，其 ClassLoader 随之失效，已加载类可被 GC，支撑真正热部署
Tomcat 的 WebAppClassLoader：按路径优先级与包名白名单控制加载顺序
Tomcat 并未抛弃双亲委派，而是反转了默认顺序——先尝试自身加载，再有选择地委托给父加载器。关键控制变量集中在加载路径和包名规则上。
- 加载路径优先级：WEB-INF/classes → WEB-INF/lib/*.jar → 父加载器（SharedClassLoader 或 CatalinaClassLoader）
- 核心类强制委托：所有
java.*、javax.*（除javax.servlet.*等容器 API）、org.apache.catalina.*类，一律跳过本地查找，直交父加载器 - 容器 API 特殊处理：
javax.servlet.*等由 Tomcat 提供的类，既不交给 Bootstrap，也不交给 AppClassLoader，而是由 CatalinaClassLoader 加载，确保 Web 应用看到统一版本 - 热部署依赖：WebAppClassLoader 可被整体替换，旧实例无引用后，其所加载的类随 GC 回收，新请求走新加载器
线程上下文类加载器（ContextClassLoader）：在调用链中临时注入子加载器能力
这是最轻量的“打破”方式，不修改类加载器结构，只在特定执行点切换加载上下文。JDBC 驱动加载是经典案例。
-
DriverManager在rt.jar中，由 Bootstrap 加载；而com.mysql.cj.jdbc.Driver在应用 classpath，只能由 AppClassLoader 加载 - JDBC 规范要求
DriverManager.getConnection()内部通过Thread.currentThread().getContextClassLoader()加载驱动类 - 应用启动时，Tomcat 或 Spring Boot 会将当前线程的 ContextClassLoader 设为 WebAppClassLoader，使高层 API 能触达底层实现
- 使用时需注意：手动设置后务必恢复原值，避免线程复用导致类加载器污染
变量控制的核心差异：你真正能改的是什么
OSGi 控制的是“谁能看到谁”，靠元数据契约；Tomcat 控制的是“谁先加载谁”，靠路径与包名规则；ContextClassLoader 控制的是“此刻用哪个加载器”，靠线程局部变量。三者都不是粗暴删除委派逻辑，而是把加载决策权从静态继承关系转移到运行时可配置的变量上。
- OSGi 可控变量：Bundle 的
Import-Package、DynamicImport-Package、Require-Bundle、启动级别（start level） - Tomcat 可控变量：
web.xml中的loaderDelegate属性、catalina.properties的shared.loader路径、WEB-INF/web.xml的metadata-complete开关 - ContextClassLoader 可控变量：线程创建时机、设置时机、作用域范围（是否传播到子线程）、是否需要 try-finally 恢复
