ClassLoader.getParent() 返回委托链中上一级类加载器而非继承父类，如 AppClassLoader 的 parent 是 ExtClassLoader，ExtClassLoader 的 parent 为 null（对应 Bootstrap ClassLoader）。
Java 类加载器通过双亲委派模型形成树状委托链路，ClassLoader.getParent() 是获取上一级类加载器的关键方法，但要注意它返回的是直接父加载器，不是“继承关系”中的父类。
理解 getParent() 返回的是委托父级，不是类继承父类
getParent() 返回的是当前类加载器在双亲委派链中**委托查找的上一级加载器**，和 Java 类的 extends 无关。例如：
- 应用类加载器（AppClassLoader）的 parent 是扩展类加载器（ExtClassLoader）
- 扩展类加载器的 parent 是启动类加载器（Bootstrap ClassLoader）
- 但启动类加载器由 C++ 实现，Java 层无法直接引用，所以
ExtClassLoader.getParent()返回null
逐级向上追溯的标准写法
用循环调用 getParent() 即可打印完整委托链，注意判空终止：
ClassLoader cl = Thread.currentThread().getContextClassLoader();
int level = 0;
while (cl != null) {
System.out.println(level + ": " + cl.getClass().getSimpleName() + " [" + cl + "]");
cl = cl.getParent();
level++;
}
// 输出类似：
// 0: AppClassLoader [sun.misc.Launcher$AppClassLoader@18b4aac2]
// 1: ExtClassLoader [sun.misc.Launcher$ExtClassLoader@5acb987e]
// 2: null （表示到 Bootstrap）
常见误区与注意事项
以下情况容易导致链路误判：
立即学习“Java免费学习笔记（深入）”；
-
自定义 ClassLoader 可能不设置 parent：若构造时未显式传入 parent，默认使用
ClassLoader.getSystemClassLoader()；但若手动传null，则链路在此中断 -
Bootstrap ClassLoader 不是 Java 对象：它没有 Java 类型实例，因此任何加载器调用
getParent()到达它时都会返回null，这是正常终点 - 线程上下文类加载器（TCCL）可能打破默认链：比如 Web 容器会把 WebAppClassLoader 设为 TCCL，它的 parent 通常是共享库加载器，而非 AppClassLoader，需单独检查
验证委托行为的实际技巧
光看链路不够，可配合 loadClass() 调试确认是否真走委托：
- 重写自定义加载器的
loadClass(String name, boolean resolve)，在开头加日志：System.out.println("[" + this + "] loading " + name); - 再调用
super.loadClass(name, resolve)—— 这会触发标准双亲委派流程 - 观察日志顺序，就能看到实际委托路径是否与
getParent()链一致
不复杂但容易忽略：getParent() 揭示的是设计上的委托层级，而真正运行时的加载路径还受 TCCL、自定义逻辑、JDK 版本差异影响，建议结合调试日志交叉验证。
