双亲委派模型是JVM类加载器的协作规则，即类加载器收到请求后优先委派给父加载器，仅当父加载器无法加载时才自行加载；其本质是“向上委托、向下fallback”的逻辑层级关系，非继承关系。
双亲委派模型不是“两个父母”，而是指类加载器在加载类时，**优先把请求交给自己的父加载器处理，只有父加载器明确无法加载时，才自己动手**。它本质是一套“向上委托、向下 fallback”的协作规则，不是继承关系，而是逻辑上的层级委托。
工作原理：两阶段流程很清晰
整个过程分为“向上委派”和“向下加载”两个阶段：
- 先查是否已加载：当前类加载器首先检查该类是否已被自己或任意父加载器加载过（通过缓存判断），若已存在，直接返回 Class 对象，避免重复加载。
-
再向上委派：如果未加载，不自己找，而是调用
parent.loadClass()把请求交给父加载器；这个动作逐层上推，直到启动类加载器（Bootstrap）。 -
顶层开始尝试：启动类加载器在其负责路径（如
$JAVA_HOME/jre/lib/rt.jar）中查找；找不到就返回 null，请求下放给扩展类加载器（Extension）。 -
逐级回落加载：扩展类加载器查
lib/ext；再失败，才轮到应用类加载器（Application），在 classpath 或 jar 包里找；全都失败则抛出ClassNotFoundException。
三大默认加载器的分工与委托链
JVM 默认提供三层加载器，形成一条明确的委托链（父→子）：
-
启动类加载器（Bootstrap）：C++ 实现，加载
java.lang.*等核心类；没有 Java 层父加载器（getClassLoader()返回 null）。 -
扩展类加载器（Extension）：Java 实现，父加载器是 Bootstrap；负责
lib/ext下的扩展类。 - 应用类加载器（Application）：也叫系统类加载器，父加载器是 Extension；加载 classpath 下所有用户类和第三方库（如 Spring、Log4j）。
你写的自定义类加载器，通常以 Application 为父加载器，自然融入这条链。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
为什么需要它？三个关键优势直击痛点
双亲委派不是为了炫技，而是解决真实问题：
-
防止核心类被篡改：比如你写了个
java.lang.String，想用自定义加载器替换掉 JDK 自带的。但双亲委派会让请求一路上传到 Bootstrap，它先加载了真正的String，你的版本根本没机会执行——保障了 JVM 基础安全。 -
避免同一类被多次加载：不同加载器如果各自加载同一个类，会产生多个互不兼容的 Class 对象（哪怕字节码完全一样），造成
ClassCastException。委派机制确保“谁先加载谁说了算”，全局唯一。 - 实现天然的类隔离：Web 容器（如 Tomcat）靠打破双亲委派来隔离不同 WebApp 的类；反过来，标准委派正是这种隔离能力的前提——每个加载器有自己的命名空间，而委托链让边界更可控。
什么时候会破坏它？不是 bug，是必要设计
双亲委派是默认行为，但不是铁律。某些场景必须绕过它：
-
JDBC 驱动加载：
DriverManager在 Bootstrap 中，但驱动实现类（如com.mysql.cj.jdbc.Driver）在应用 classpath 下。Bootstrap 无法加载它，所以 JDBC 使用线程上下文类加载器（TCCL），由 Application 加载驱动。 - OSGi、Tomcat、Spring Boot 的嵌套 jar：需要模块间类隔离或热部署，它们会自定义加载策略，主动中断委派链。
破坏不等于否定——正因有标准模型，才能清楚知道哪里该破、怎么破、为何破。
