Bootstrap类加载器由JVM用C++实现，无Java实例，负责加载rt.jar（JDK8–）或java.base.jmod（JDK9+）等核心类库，位于委派链顶端，无父加载器，调用getClassLoader()返回null。
Java 引导类加载器（Bootstrap ClassLoader）不通过 Java 代码实现，而是由 JVM 用 C++ 等本地语言内置完成，它直接从 JVM 启动时就存在，负责加载最底层、最关键的运行时类库。
加载路径明确固定
它默认从以下位置加载核心类文件：
- $JAVA_HOME/jre/lib/rt.jar（JDK 8 及以前）——包含 java.lang、java.util、java.io 等全部标准 API 类
- JDK 9+ 模块化后，改由 $JAVA_HOME/jmods/ 下的 jmod 文件提供，如 java.base.jmod
- 其他关键资源如
resources.jar、jsse.jar、jce.jar等也由它一并载入
不依赖父加载器，也不对外暴露
引导类加载器处于整个类加载器层次的顶端：
- 没有父类加载器，
ClassLoader.getSystemClassLoader().getParent().getParent()返回null - 在 Java 层不可见、不可直接引用或实例化，任何调用
String.class.getClassLoader()都得到null - 它的存在早于 Java 应用线程启动，是 JVM 初始化阶段最先激活的加载器
加载行为完全由 JVM 控制
你无法修改它的逻辑，但可通过 JVM 参数微调其行为：
立即学习“Java免费学习笔记（深入）”；
-
-Xbootclasspath：可替换或追加引导类路径（慎用，破坏稳定性风险高） -
-Xbootclasspath/a:：追加到默认引导路径末尾 -
-Xbootclasspath/p:：插入到默认引导路径开头（可能覆盖核心类，极危险）
它不参与双亲委派的“发起端”，而是委派链的终点
当 AppClassLoader 收到一个类加载请求（比如 java.lang.Object），流程是：
- AppClassLoader → 委托给 ExtClassLoader → 再委托给 Bootstrap ClassLoader
- Bootstrap 尝试从 rt.jar 或 jmod 中定位该类；若找到，直接定义并返回 Class 对象
- 若未找到，才逐级向下回退，最终由发起者尝试加载（但核心类绝不会落到这一步）
