Java类加载器层级关系本质是“谁委托谁”的委派链，含Bootstrap（加载java.核心类）、Extension（加载javax.扩展类）、Application（加载应用类）及自定义加载器，共同实现双亲委派机制。
Java 中分析类加载器的层级关系，关键不是看“谁继承谁”，而是看“谁委托谁”——这是一种逻辑上的委派链，而非 Java 类的继承链。理解它，要从职责、可见性、加载路径和实际行为四方面入手。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
启动类加载器（Bootstrap ClassLoader）是顶层委托者
它是 JVM 启动时最先工作的加载器，用 C/C++ 实现，不继承自 java.lang.ClassLoader，所以在 Java 代码中调用 getClassLoader() 得到 null。它只加载最核心的类：
- 路径固定：
$JAVA_HOME/jre/lib/rt.jar（或模块化后的java.base等系统模块） - 类名特征：严格限定为
java.*开头，比如java.lang.Object、java.util.HashMap - 不可干预：开发者无法直接使用、替换或扩展它，它的存在是为了兜底安全
扩展类加载器（Extension ClassLoader）是中间承上启下的一环
它由 Java 编写（sun.misc.Launcher$ExtClassLoader），父加载器逻辑上是启动类加载器（getParent() 返回 Bootstrap 的包装或 null）。职责明确：
- 加载位置：默认
$JAVA_HOME/jre/lib/ext目录，或由java.ext.dirs系统属性指定的路径 - 典型内容：
javax.*包下的类（如javax.crypto.*）、部分安全框架、国际化支持等 - 设计意图：让 JDK 具备可插拔能力，无需改动 JVM 就能引入标准扩展
系统类加载器（Application/System ClassLoader）是应用代码的默认加载者
它也是 Java 实现（sun.misc.Launcher$AppClassLoader），父加载器是扩展类加载器。绝大多数日常开发都和它打交道：
- 加载来源：环境变量
CLASSPATH、-cp参数、IDE 的 output 目录、Maven 构建产物（target/classes）等 - 实际覆盖：你自己写的
com.example.User、Spring、Log4j、Jackson 等所有第三方 jar 中的类 - 可显式获取：
ClassLoader.getSystemClassLoader()返回的就是它，常作为自定义加载器的默认父加载器
自定义类加载器处于委派链末端，但必须尊重双亲委派
你写的类加载器需继承 java.lang.ClassLoader，默认构造会把系统类加载器设为父加载器。它不自动破坏规则，除非你重写 loadClass() 方法绕过 super.loadClass()。常见用途包括：
- 从网络、数据库或加密文件中加载字节码
- 实现热部署（如 Tomcat 为每个 WebApp 创建独立加载器）
- 隔离不同插件的类（避免版本冲突）
这种分层的本质，是为双亲委派机制服务：每个加载请求都先向上递交，只有上级明确“找不到”，才轮到下级动手。这样既防住了 java.lang.String 被恶意替换，也避免了同一类被多个加载器重复加载。
