JVM中不存在“用于存储类元数据的双亲委派双向链表结构”；双亲委派是单向委托策略，类元数据存于Metaspace，由ClassLoaderData管理，二者完全解耦。
JVM 内部并不存在“用于存储类元数据的双亲委派双向链表结构”。
这是一个常见的概念混淆。需要直接澄清：
- 双亲委派（Parent Delegation）不是一种数据结构，而是一种加载策略或行为协议；
- 类元数据（如类名、方法表、字段信息、常量池等）存储在方法区（Metaspace，HotSpot 中）中，与类加载器实例无关；
- 类加载器之间确实存在 parent 引用关系，但它是单向的（parent 指针），不是双向链表，也不用于“存储类元数据”。
下面分三部分帮你理清本质：
类加载器的 parent 引用是单向、树状的委托链
每个 ClassLoader 实例内部持有一个 private final ClassLoader parent 字段（见 java.lang.ClassLoader 源码）。
这个引用构成的是自底向上的一条单向委托路径，例如：
MyCustomClassLoader → AppClassLoader → ExtClassLoader → null （Bootstrap ClassLoader 不是 Java 对象，无 parent）
它不构成“链表”，更不是“双向”——子加载器知道父是谁，但父完全不知道子的存在。也没有遍历子加载器的设计或需求。
类元数据存在哪？跟双亲委派无关
- 类的字节码解析后生成的
Klass（HotSpot 内部表示）、Method*、ConstantPool等元数据，统一存放在 Metaspace（元空间） 中（JDK 8+）； - Metaspace 是堆外内存区域，由
ClassLoaderData（CLD）管理，每个类加载器拥有一个ClassLoaderData实例； -
ClassLoaderData记录该加载器定义的所有类（Klass链表），但它不维护与其他加载器的结构关系，也不参与双亲委派逻辑。
✅ 简单说：双亲委派决定“谁来触发加载”，Metaspace 决定“类信息存在哪”，二者解耦。
“双向链表”误解可能来自哪？
- 误读了
ClassLoaderData中loaded_classes的链表结构（它是单向链表，仅用于 GC 标记和卸载）； - 混淆了类加载器实例的
parent引用和ClassLoaderData的next指针（后者用于 CLD 自身链表管理，与委派无关）； - 将 JVM 调试工具（如
jhsdb或Serviceability Agent）中展示的加载器层级视图，脑补成了底层双向数据结构。
真正关键的机制，始终是 loadClass() 方法中的委派逻辑：
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
Class<?> c = findLoadedClass(name); // 先查缓存（本加载器已加载过？）
if (c == null) {
if (parent != null) {
c = parent.loadClass(name, false); // 委派给 parent（单向调用）
} else {
c = findBootstrapClassOrNull(name); // 到 Bootstrap（C++ 层）
}
}
if (c == null) {
c = findClass(name); // 父都失败，才自己 load
}
if (resolve) resolveClass(c);
return c;
}这段代码体现的是控制流的上下传递，不是数据结构的双向维护。
不复杂但容易忽略：双亲委派的本质是设计模式中的“责任链（Chain of Responsibility）”，而非某种物理链表。
