在J*a中双亲委派何时会被破坏_J*a类加载模型例外情况讲解

新闻中心 NEWS CENTER

2025-12-12

浏览次数：次

双亲委派被破坏的典型场景有四类：1. 线程上下文类加载器（TCCL）用于SPI加载；2. 模块化容器如OSGi实现类隔离；3. JDK自身对动态代理、Lambda等的特殊处理；4. 用户自定义ClassLoader主动绕过。

在java中双亲委派何时会被破坏_java类加载模型例外情况讲解

J*a 的双亲委派模型不是铁律，而是一种设计约定。在实际开发和 JDK 自身演进中，有几种明确且合理的“破坏”方式，它们不是 bug，而是为了解决特定问题而做的主动绕过。

这是最常见、最标准的破坏方式。当高层框架（如 JNDI、JDBC、JAXP）需要加载由应用开发者提供的实现类时，它无法通过当前类加载器（比如 Bootstrap 或 Extension 类加载器）去加载应用目录下的类——因为双亲委派会一路向上，最终失败。

解决办法是：让线程绑定一个能加载业务类的类加载器（通常是 AppClassLoader），框架内部显式调用 Thread.currentThread().getContextClassLoader() 来加载 SPI 实现。

JDBC 驱动注册就是经典例子：DriverManager 在 Bootstrap 类加载器中，但它通过 TCCL 去加载 com.mysql.cj.jdbc.Driver 这类位于 classpath 下的驱动类
Tomcat 为每个 Web 应用设置独立的 WebAppClassLoader，并将其设为线程上下文类加载器，确保 Servlet 能加载本应用的类

OSGi、Spring Boot DevTools、JRebel 等工具为了实现模块热替换或类隔离，会构造多层级、网状甚至并行的类加载关系，完全不遵循“父优先”原则。

OSGi 中每个 Bundle 拥有独立的类加载器，依赖通过 Import-Package 显式声明，查找类时先查自己 bundle，再查导入包，最后才可能委托给父加载器
这类加载器通常重写 loadClass() 方法，跳过 super.loadClass()，直接从本地资源或缓存加载

部分核心类虽在启动阶段加载，但其行为本身绕过了标准流程：

微软爱写作

微软出品的免费英文写作/辅助/批改/评分工具

130 查看详情微软爱写作

j*a.lang.ClassLoader 是由 Bootstrap 加载器加载的，但它自身是一个 J*a 类，其 defineClass() 等方法允许子类直接定义类字节码，无需委派
动态代理（Proxy.newProxyInstance()）、Lambda 表达式生成的类，由 sun.misc.Launcher$AppClassLoader（或自定义类加载器）直接 defineClass，不经过 findClass → parent.loadClass 流程
String.intern() 缓存的字符串对象不涉及类加载，但常被误认为“破坏委派”，其实无关