引导类加载器由C++实现、不继承ClassLoader、加载rt.jar或系统模块的核心类（如java.lang.Object），返回null；扩展类加载器是Java类（ExtClassLoader）、继承ClassLoader、父加载器为引导类加载器，加载ext目录或java.ext.dirs指定路径的扩展类（如javax.crypto.*）。
引导类加载器和扩展类加载器是 JVM 类加载体系中最基础的两级，它们分工明确、层级清晰，理解它们的关键在于抓住“谁来加载”“加载什么”“怎么协作”这三点。
引导类加载器：JVM 的根基，不露面但管全局
它不是 Java 写的，而是由 JVM 用 C++ 实现的原生组件，不属于 Java 类继承体系——所以 不继承 ClassLoader，也没有父加载器。你调用 String.class.getClassLoader() 得到的是 null，这就是它的“隐身”特征。
它只负责加载最核心的运行时类，比如 java.lang.Object、java.util.ArrayList、java.io.* 等，来源固定：
– JDK 8 及之前：主要来自 $JAVA_HOME/jre/lib/rt.jar
– JDK 9+：来自 java.base 等系统模块
这些类是整个 Java 运行环境的基石，一旦出错，JVM 都无法启动。
它还承担一个隐性职责：加载后续的扩展类加载器和系统类加载器本身。也就是说，ExtClassLoader 和 AppClassLoader 这两个 Java 类，其实是被引导加载器“亲手”载入内存的。
扩展类加载器：Java 编写的“中间层”，专管通用扩展
它是标准的 Java 类，全名是 sun.misc.Launcher$ExtClassLoader，继承自 ClassLoader，能被 Java 代码直接引用和操作。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
它的父加载器就是引导类加载器，遵循双亲委派：收到类加载请求时，先让引导类加载器尝试；失败后才自己出手。
它加载的类不是核心，但属于“通用增强型”，例如：
– javax.crypto.*（加密支持）
– javax.xml.*（XML 解析）
– 其他放在 $JAVA_HOME/jre/lib/ext 或由 -Djava.ext.dirs 指定路径下的 JAR 包
注意：java.ext.dirs 是覆盖式配置，不是追加——设了新路径，就不再扫描默认 ext 目录。
两者如何协作？看一个典型加载过程
当你写 new javax.crypto.Cipher() 时：
- 应用类加载器（AppClassLoader）收到请求，按规则先委托给父加载器
- 扩展类加载器（ExtClassLoader）接手，先问引导类加载器：“你认识
javax.crypto.Cipher吗？” - 引导类加载器查
rt.jar和系统模块，发现没有（因为javax.crypto不在核心包里），返回失败 - 扩展类加载器接着在
ext目录下找到crypto.jar，成功加载并返回 Class 对象
这个过程体现了双亲委派的价值：既保证核心类不被替换，又让扩展能力可插拔、不侵入核心。
常见误区提醒
– 引导类加载器 ≠ “启动时才工作”：它全程在线，所有核心类的首次使用都经它之手
– 扩展类加载器 ≠ “可有可无”：虽然 JDK 9+ 模块化弱化了 ext 目录，但在兼容场景或某些容器中仍被使用
– getParent() 返回 null 不代表“没爹”，而是设计使然：引导类加载器是整个委派链的起点，不可再向上委托
