引导类加载器由c/c++实现，不继承classloader，故string.class.getclassloader()返回null；它直接读取rt.jar字节码，跳过委派机制，硬编码加载核心类到方法区，是双亲委派的顶层终点与信任锚点。
引导类加载器（Bootstrap Class Loader）不通过 Java 代码实现，而是由 JVM 本地代码（通常是 C/C++）在启动时直接完成加载，它本身不依赖任何 Java 类加载器，也不受双亲委派机制约束。
引导类加载器怎么加载 rt.jar
它的工作方式和普通类加载器完全不同：
- JVM 启动初期就硬编码识别
rt.jar（或模块化后的java.base等核心模块）所在路径，比如$JAVA_HOME/jre/lib/rt.jar（JDK 8 及之前）或$JAVA_HOME/lib/modules（JDK 9+ 模块化后） - 用本地 I/O 直接读取 JAR 文件字节，解析 ZIP 结构，逐个提取
.class文件的二进制流 - 跳过常规的“委托—查找—加载”流程，直接将核心类（如
java.lang.Object、java.lang.String）的字节码载入方法区，并完成验证、准备、初始化等阶段 - 整个过程不经过
ClassLoader.defineClass()，也无需调用 Java 层的加载逻辑，因此无法被 Java 代码直接引用或扩展
为什么获取不到它的实例
因为它是 JVM 内置的原生组件：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
String.class.getClassLoader()返回null，不是“没设置”，而是 JVM 明确设计为不暴露该加载器的 Java 对象引用 - Java 规范规定：Bootstrap Class Loader 不是
java.lang.ClassLoader的子类，它没有对应的 Java 类，自然无法实例化或继承 - 这种设计既保证了核心类的绝对可信与不可篡改，也避免了用户代码意外干扰基础运行环境
它和双亲委派的关系
它是委派链的顶层，但不参与“委派”动作：
- 当应用类加载器收到加载
java.util.ArrayList的请求，会逐级向上委托——先到扩展类加载器，再到系统类加载器，最终到达 Bootstrap - Bootstrap 接收到请求后，不转发给任何父加载器（它没有父加载器），而是直接查自己已加载的核心类表；命中则返回 Class 对象，未命中则返回失败，交由下级尝试
- 所以它不是“执行委派”的一环，而是“委派终点”和“信任锚点”
实际影响举例
比如你写了一个同名类：java.util.HashMap，放在 classpath 下：
- 编译能通过（语法无冲突）
- 但运行时永远加载的是 Bootstrap 加载的 JDK 自带版本，你的类根本不会被使用——因为委派机制会在最上层就命中并返回
- 这是 JVM 防止核心类被恶意替换的关键防线
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
