双亲委派模型是类加载的协作规则，非强制协议：先查缓存，再委托父加载器（直至Bootstrap），最后才由当前加载器调用findClass；Java 17起分为Bootstrap、Platform、App三层加载器；核心意义在于防篡改、保唯一、稳依赖；可打破但需正当理由。
双亲委派模型不是“两个父母”，而是“先找父加载器，父搞不定再自己来”。它本质是类加载的协作规则，不是强制协议，但 JVM 内置加载器默认严格遵循，目的是让核心类稳如磐石、业务类各安其位。
工作流程：向上委托 → 自上而下尝试 → 逐级回落
当某个类加载器（比如你写的自定义加载器）收到 loadClass("com.example.Service") 请求时，实际执行分三步：
- 先查缓存：检查自己是否已加载过该类（避免重复加载），有则直接返回 Class 对象；
-
再往上交：调用
parent.loadClass()，把请求递交给父加载器；这个动作会一路向上，直到启动类加载器（Bootstrap）； -
最后才动手：只有当所有上级都返回
null（即找不到该类），当前加载器才调用findClass()从自己的路径（如 jar、文件系统）中读取字节码并 define。
类加载器层级：Java 17 起已简化为三层
不再有“扩展类加载器”这个独立角色，取而代之的是更清晰的平台级划分：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
-
启动类加载器（Bootstrap）：C++ 实现，加载
java.base等核心模块（String、Object等），无 Java 对象，getClassLoader()返回null； -
平台类加载器（Platform）：替代旧版 Extension，加载
java.sql、java.xml等 JDK 平台模块； -
应用类加载器（App / System）：加载 classpath 或模块路径下的业务代码，默认线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）； -
自定义类加载器：继承
ClassLoader，父加载器默认是 App 类加载器，可重写findClass()实现热部署、插件隔离等场景。
核心意义：安全、唯一、可预测
这机制不是为了炫技，而是解决三个关键问题：
立即学习“Java免费学习笔记（深入）”；
-
防篡改：确保
java.lang.Integer永远由 Bootstrap 加载——你哪怕在 classpath 放一个同名类，也不会被 App 加载器加载，杜绝恶意替换核心类； -
保唯一：同一全限定名的类，在整个 JVM 中只被一个加载器加载一次，避免因不同加载器重复加载导致
ClassCastException（比如两个MyService类虽字节码相同，但因加载器不同而视为不同类型）； -
稳依赖：上层类（如你自己写的 Service）引用
java.util.List，必然通过 Bootstrap 加载，不会因某插件自带低版本 List 而引发冲突，保障运行时行为可预期。
打破它？可以，但得有正当理由
双亲委派不是铁律。JDBC 的 DriverManager 就主动打破——它用线程上下文类加载器（通常是 App 加载器）去加载用户注册的驱动类（如 com.mysql.cj.jdbc.Driver），因为 Bootstrap 根本看不到这些第三方类。类似场景还有 OSGi、Tomcat 的 webapp 隔离、Spring Boot 的 DevTools 热重启。打破方式通常是绕过 loadClass()，直接在子类中调用 findClass() 或使用上下文类加载器。
