类加载器双向引用与Bootstrap C++创世之谜解析-代码聚汇网

类加载器双向引用与Bootstrap C++创世之谜解析

用户甲·2026-09-01·阅读 27 GEO检测（免费）

类加载器双亲委派Bootstrap ClassLoader

|难度：普通|阅读约 40 分钟

这标题拿到手，我就知道这不是一篇“科普什么是双亲委派”的文章。它值得聊的，是两件很多人没完全想透的事：第一，类加载器里那些“引用”到底怎么互相指来指去，为什么网上传的“双向强引用”说法既对又不全对；第二，整个类加载体系的最源头——Bootstrap ClassLoader——明明是Java层看不见的null，它却是怎么被一个C++写的JVM“亲手”造出来的。这两个问题一旦想通，很多模棱两可的面试题和线上诡异问题都能一次性串起来。

先说个总判断：双亲委派模型的本质是一条“向上委派、向下兜底”的单向链路，但类加载器体系里确实存在多组双向的、互相强引用的关系。比如类对象持有加载它的类加载器引用，类加载器内部又缓存着所有已加载的类对象；子加载器持有父加载器引用用于委派，类加载失败时父加载器的名字又会出现在异常堆栈里。这些关系叠加起来，才是标题说的“双向”的真正内涵。而“C++创世之谜”，指的是HotSpot这坨C++代码在Java对象还没来得及出现时，如何先手工把Object、Class、String、ClassLoader这些最底层的类“孵化”出来，再拐回Java世界正式启动类加载体系。

下面我按一条从“引用关系”到“委派逻辑”，再到“工程后果”“底层创世”和“调优排查”的路径拆开讲，尽量把每个“为什么”都说到位。

1. 从“双向强引用”这个说法说起：类加载器机制里到底谁引用了谁

1.1 一个容易让人误会的非正式术语

“双向强引用”并不是JVM规范里的正式术语，它更像是社区里对类加载器机制中一组引用关系的口语化概括。这导致很多人在面试时一听到“双向强引用”就脱口而出“双亲委派嘛，子加载器把请求抛给父加载器”，然后面试官追问一句“那父加载器怎么反向拿到子加载器的类？”，一下子就卡住了。

实际上，类加载器之间的关系是典型的“单向引用、单向可见”。一个类加载器持有父加载器引用，是为了把加载请求向上传递；父加载器手里没有任何子加载器的引用，它压根不知道下面有几个子加载器。父加载器对子加载器唯一的“反向”作用，是当子加载器找它要类时，它把已经加载好的类或者加载能力“借”给子加载器，仅此而已。

1.2 子加载器持有父加载器，父加载器不持有子加载器

这段引用关系在代码里非常直观。打开java.lang.ClassLoader的源码，你会看到一个字段：

java复制// 父类加载器，用于向上委派
private final ClassLoader parent;

这个字段就是“子→父”引用的全部。AppClassLoader创建时把自己parent设为PlatformClassLoader（JDK 8里是ExtClassLoader），PlatformClassLoader的parent设为null。null在这里不代表没有父类加载器，而是代表“上一个已经是BootstrapClassLoader，它在Java层没有对象”。

所以，一个类加载器在内存中的引用结构长这样：

子加载器对象中有一个parent字段，强引用父加载器。
父加载器的内存里没有“children列表”，它不知道谁在用它做父加载器。
类加载器的父级链可以通过ClassLoader.getParent()遍历出来，但往下是遍历不到的。

这套设计使得类加载器体系像一棵“单向链表构成的树”，只能从头往下查询，不能从下往上枚举。这也是为什么排查类加载器泄漏时，通常只能从堆快照里找到持有某个加载器的对象，再反向推导引用链，而没有现成的API能列出“谁是这个加载器的子加载器”。

1.3 类对象与类加载器的互相持有：真正的“双向强引用”

如果说加载器之间的引用是单向的，那“双向强引用”主要体现在类对象和类加载器之间。这一对关系才是很多人忽略的重点。

每个被加载出来的Class对象内部都会记住“我是谁加载的”。在HotSpot实现中，类对象内部有一个指向ClassLoaderData的引用，Java反射层面则表现为Class.getClassLoader()方法能返回加载它的类加载器。反过来，类加载器内部对已加载类的缓存也一直在持有类对象的引用，类加载的“findLoadedClass”之所以快，靠的就是这个缓存。

于是你看到了一个闭合的强引用环：类加载器 → 已加载类对象 → 加载器本身。这个环在正常运行时没什么问题，但当你想让一个类加载器及其加载的所有类“整体卸载”时，麻烦就来了：只要环上有任何一个外部强引用，整条链上的所有类和加载器就都回收不掉。这是后面要讲的Metaspace泄漏的根源，也是容器类热部署实现很吃力的核心原因。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 双亲委派模型的真实工作逻辑：方向、边界与可见性规则

2.1 委派请求向上走，实际加载在落点处发生

双亲委派模型的工作流程，用一句话说就是“向上请求，向下兜底”。以JDK 8的加载链为例，当应用程序调用ClassLoader.loadClass("com.example.MyService")时，实际发生的是：

AppClassLoader先检查自己缓存里有没有com.example.MyService，有就直接返回。
没有，就调用parent.loadClass("com.example.MyService")，把请求交给ExtClassLoader。
ExtClassLoader会继续把请求交给它的parent，也就是null，触发BootstrapClassLoader尝试加载。
BootstrapClassLoader在自己的加载路径里找不到这个类，回一个ClassNotFoundException。
ExtClassLoader接收到异常，自己尝试在lib/ext目录（JDK 9后是Platform类加载器的模块路径）里找，找不到再抛异常。
AppClassLoader收到两次失败后，自己尝试在classpath里找，找到了就加载并返回。

核心逻辑用JDK 8的loadClass方法伪代码来看特别清楚：

java复制protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }
            if (c == null) {
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

有几个容易忽略的细节。

一是同步锁。getClassLoadingLock保证了同一个类加载器并发加载同一个类时不会重复加载。JDK 7之后默认使用ClassLoader对象本身加锁，开启并行类加载时则用类名对应的锁对象。多线程环境下这个synchronized块是保证“一个类只被加载一次”的老家底。

二是“从父到子的反向”。委派请求是向上走的，但实际“返回类”的方向是反过来的。Bootstrap如果找到了类，会沿着调用栈一层层返回给最下面的请求者；如果每级都没有，最终才轮到最初发起请求的加载器自己findClass。所以与其说双亲委派是“父加载器帮子加载器加载”，不如说它是“子加载器请求父加载器优先加载，父加载器不行再自己想办法”。

三是findBootstrapClassOrNull这个分支。子加载器判断parent == null时，会直接让Bootstrap尝试加载核心类。这意味着所有加载器最终都能通过这条分支访问到核心JDK类，但反过来Bootstrap却不知道任何子加载器加载的类，这直接决定了类加载器体系中的可见性规则。

2.2 可见性规则：向下可见，向上不可见

在双亲委派模型下，子加载器能看见父加载器加载的所有类，父加载器看不见子加载器加载的任何类。这个不对称的可见性是从委派逻辑直接推导出来的，不需要额外记住。

举个例子：Bootstrap加载了java.lang.String，所以所有类加载器在加载代码里遇到String时，委派到最顶端就会拿到Bootstrap的String，大家用的都是同一个类。反过来，AppClassLoader加载了com.example.MyServiceImpl，如果Bootstrap或者ExtClassLoader加载的代码想引用这个类，它连“怎么去找”都不知道，因为向上委派时根本不会经过子加载器。

这造成了一个经典问题：JDK 8时代，java.sql.DriverManager由Bootstrap加载，但它要管理的JDBC驱动实现（比如MySQL驱动）却躺在classpath里，属于AppClassLoader可见范围。Bootstrap根本看不到这个驱动类。这就是为什么JDBC代码需要用到“打破双亲委派”的机制——第三方服务提供者接口的经典困境。

2.3 这种“单向”设计背后的安全考量

如果你问为什么非要搞成向上委派而不是向下委派，除了“避免重复加载”的工程原因，更重要的是安全。

假设没有双亲委派，每个加载器都自己先找类，那么你在classpath里塞一个自定义的java.lang.String，应用代码里的String就可能被你自己的加载器优先加载，整个类型体系就乱套了，核心API的安全性无从谈起。双亲委派保证所有Java代码的String、Object、Class等核心类型永远由Bootstrap从JDK自带路径加载，你想写一个“假String”顶替它？先过Bootstrap这关，这关根本不会给你“顶替”的机会。

所以双亲委派模型的本质不是“性能优化”，而是“身份统一”和“安全边界”。这个视角在面试里很加分，因为大多数人只把它当成一个“避免重复加载”的机制，而没意识到它其实是JVM类型安全体系的地基之一。

3. 强引用闭环的工程后果：内存泄漏、类型唯一性与类冲突

3.1 类型唯一性：同一个类为什么可以被加载两次

Java类型唯一性的判断标准是“类加载器 + 全限定类名”二元组。同一个com.example.User，由AppClassLoader加载一次，再被WebAppClassLoader加载一次，它们就是两个完全不同的类型。这两者的对象之间做instanceof判断返回false，强制类型转换直接抛ClassCastException。

这个规则我见过好多人踩坑。比如在Tomcat下做应用层缓存，缓存key只写了类名，没写类加载器，一旦应用热部署，旧的类加载器加载的缓存对象还在，新旧对象就混在一起，内存里同时存在两套几乎一样但互不兼容的类。这种问题比空指针难查得多，因为它不会在日志里直接报“类找不到”，而是报一些莫名其妙的ClassCastException或者LinkageError。

3.2 类加载器泄漏：OOM的经典元凶

回到第1章说的“类↔加载器”强引用闭环。假设你的应用里有一个全局静态Map，把某些对象按“类加载器”做key存着用来复用，或者某个长生命周期线程持有了类加载器引用，那么这个加载器就永远不会被GC回收。后果是：

加载器本身占用的内存不释放。
它缓存的所有Class对象不释放。
这些Class对应的Metaspace（JDK 8之后的类元数据区）不释放。
如果热部署反复创建新加载器，Metaspace就会一路看涨，最终触发频繁Full GC乃至OutOfMemoryError: Metaspace。

我处理过一个案例：一个中间件组件用CGLIB对业务类动态生成代理类，每次配置变更都会重新初始化并生成新的类加载器，但旧加载器被另一个组件在静态Map里缓存了，导致一天之内Metaspace涨了好几个G。这类问题的排查思路其实很固定：dump堆，找java.lang.ClassLoader的大集合，再看谁顺着强引用路径把它们“钉”在内存里。至于类加载器能不能被回收，看的是它是否“不可达”，而不是它内部的东西是否被显式清理。只要把外部的静态引用断掉，整个类加载器连同它加载的所有类就会成片消失。

3.3 Tomcat为什么给每个应用配一套类加载器

Tomcat的类加载器设计是“打破双亲委派”的正面教材。每个Web应用都有一个独立的WebAppClassLoader，它的加载顺序是“先检查自己有没有，再检查父加载器有没有”，而不是标准的“先父后子”。这样做的原因非常实际：

应用隔离：两个Web应用可能各自带了不同版本的Spring，如果都往父加载器塞，版本冲突无可避免。独立类加载器让每个应用关起门来用自己的依赖，互不干扰。
热部署：Web应用更新时直接扔掉旧的WebAppClassLoader，重新new一个，旧类连同旧加载器一起被回收。如果Servlet容器自己加载这些类，想做到应用级卸载几乎不可能。

代价是内存和复杂度的上升，而且一旦同一份类被容器和应用各加载一份，跨层类型转换就会踩到前面说的兼容性问题。架构选型时，你要清楚“隔离”和“互通”是互斥的，容器类加载器方案都是在两者之间找平衡。

4. C++创世之谜：JVM启动时第一个类加载器是怎么诞生的

4.1 HotSpot本质上是C++程序

聊到“C++创世”，首先得纠正一个认知：JVM不是一个“纯Java程序”，它的主体是HotSpot——一个用C++写成的虚拟机。你执行的java命令最终会启动一个C++进程，这个进程负责解析字节码、管理内存、调度线程、执行垃圾回收。

既然是C++进程，那就意味着JVM在启动初期，Java世界的一切都还“不存在”。没有Object对象，没有String对象，甚至没有一个Class对象。但这引出一个先有鸡还是先有蛋的问题：类加载器体系是用来加载Java类的，可是整个JVM的字面意义是“启动时先加载核心Java类才能跑Java代码”，那第一个加载动作由谁来做？答案就是C++层直接“手工”做。

HotSpot启动时，C++代码会先初始化好运行时环境，然后调用一个初始化函数，在HotSpot源码里对应“ClassLoader初始化”相关的流程。这个过程的目标非常克制：先把最基础的Java类准备好，比如java.lang.Object、java.lang.Class、java.lang.String、java.lang.ClassLoader、java.lang.System等等。这一批类不是通过“类加载器.loadClass”加载的，它们是被C++代码在内部直接加载并登记的。

4.2 Bootstrap ClassLoader：Java层看是null，C++层一直在

Bootstrap ClassLoader（引导类加载器）是整个体系里最特殊的存在。在Java代码里，你想拿到它的引用，得到的永远是null：

java复制System.out.println(String.class.getClassLoader()); // null

很多人因此以为“Bootstrap ClassLoader不存在”，其实恰恰相反，它一直都在，只是它在Java世界里没有可操作的对象而已。在HotSpot内部，Bootstrap对应着一套C++层面的加载逻辑，负责从JDK的运行路径里找核心类。Java 8及以前是去rt.jar、tools.jar这些归档里找，Java 9以后则是通过模块化运行时镜像（jrt:文件系统）里的java.base等模块来加载。

所以准确地说，Bootstrap ClassLoader是一个“由C++代码实现、在Java层没有对应实例”的加载器。它的存在方式决定了它没有parent，也不会被GC管理。你在堆快照里看不到它，但它加载的类占据着Metaspace的一大部分。

4.3 sun.misc.Launcher：C++到Java的交接

Bootstrap只负责最核心的JDK类，那谁负责创建业务里常用的AppClassLoader？答案是Java代码自己。在JDK 8里，这个入口叫sun.misc.Launcher；JDK 9以后则换成jdk.internal.loader.ClassLoaders。

Launcher本身也是一个类，所以它也必须被某个加载器加载——它由Bootstrap加载。当C++代码准备到一定阶段，HotSpot会调用Java层的Launcher，执行它的构造器，在这个构造器里依次创建：

ExtClassLoader（JDK 8）/ PlatformClassLoader（JDK 9+）
AppClassLoader，并把ExtClassLoader或PlatformClassLoader挂成它的parent

这段逻辑里最微妙的是：这些类加载器对象本身是Java对象，它们的创建由Java字节码完成，但执行这段字节码的“解释器”是C++写的，加载这些加载器类文件的“初始加载动作”也是C++层的Bootstrap完成的。也就是说，C++把最底层的类准备好，然后用“C++调用Java方法”的方式，让Java世界自己把整套类加载体系正式搭起来。这正是标题里“创世”二字的含义：类加载器的诞生不是Java世界自己的事，而是C++世界对Java世界的首个“授权”。

在HotSpot源码里，C++调用Java方法并不是直接调，而是通过类似JavaCalls的机制完成。你可以把它理解成JNI的反向操作——不是Java调用C++，而是C++调用Java。这种调用发生在JVM初始化早期，Java世界还处于非常孱弱的状态，所以参数和相关逻辑必须极其简单。

4.4 C++世界里JVM对象与类加载器的引用管理

既然聊到C++了，顺便说一个容易混淆的点：JVM内部用C++对象记录“类加载器”和“类”的对应关系。HotSpot里有一个全局结构叫SystemDictionary，它维护着“类加载器 + 类名 → 已加载类”的映射。每个类加载器对应一段ClassLoaderData，JVM根据不同ClassLoaderData归属来区分同一个全限定类名在不同类加载器下各自对应的InstanceKlass（HotSpot的C++类元数据结构）。

这就能解释前面第3章讲的问题：为什么同一个类名在不同类加载器下是不同类型？因为SystemDictionary里，同一个类名在“AppClassLoader的ClassLoaderData”和“WebAppClassLoader的ClassLoaderData”下各有一份独立的InstanceKlass，它们指向互不相干的两套类元数据。JVM在做类型检查时，遵循的就是这个二进制级别唯一的身份规则。

5. 架构设计绕不开的类加载器边界：SPI、容器隔离与类型冲突

5.1 NoClassDefFoundError 和 ClassNotFoundException，别再混为一谈

面试题常客，也是线上排查常客，但很多人始终没分清。这两者的区别一句话就能说清：

ClassNotFoundException：主动加载一个类时，类加载器在整个委派链上都找不到它。典型场景是反射调用Class.forName("com.example.NotExist")，代码里用了Class.forName或者loadClass，并且显式处理了这个异常。
NoClassDefFoundError：类在编译期存在，运行期链接时找不到它的定义。典型场景是new一个类时，这个类的某个静态字段类型、父类或者接口不存在，或者这个类在初始化时抛了异常，JVM标记它为“不可用”，后续再引用就抛这个Error。

举个例子：你编译了一个依赖com.example.Common的类，但运行classpath里没有这个依赖，JVM在链接阶段发现Common加载不了，最终抛NoClassDefFoundError。而Class.forName("com.example.Common")找不到时，抛的是ClassNotFoundException。

线上经常出现的NoClassDefFoundError，其实还有一个隐蔽来源：类的静态初始化抛异常。JVM会把初始化失败的类标记为“错误状态”，下次有代码引用它，连尝试重新初始化都不会，直接抛NoClassDefFoundError，根因却藏在第一次的ExceptionInInitializerError里。排查时务必找全日志，别被表面异常带偏。

5.2 SPI机制为什么必须打破双亲委派

JDBC是理解SPI（Service Provider Interface）的经典案例。java.sql.DriverManager由Bootstrap加载，它运行时需要加载各个数据库厂商的驱动实现类，而驱动类的JAR包通常在应用classpath里，本质上是AppClassLoader或WebAppClassLoader管辖的范畴。前面说了，Bootstrap对子加载器加载的类完全不可见，这就是“父加载器看不见子加载器”的典型死局。

打破僵局的工具是线程上下文类加载器（Thread Context ClassLoader，简称TCCL）。JVM允许每个线程设置一个“当前线程的默认类加载器”，默认是AppClassLoader。DriverManager不再走双亲委派，而是直接问当前线程：“你的TCCL是谁？”然后把TCCL拿过来加载驱动类。

所以你可以看到这种反直觉的现象：委派模型是向上求援，而SPI是父级代码主动向下，借子级加载器的力量来加载一个自己看不见的类。现代很多框架，包括Spring、JDBC、JNDI、日志门面，都在用TCCL来打通“框架代码看不见实现类”的隔阂。

对于架构设计，这里有一个非常重要的经验：如果你的框架代码要被Bootstrap或平台类加载器加载，同时它又需要加载应用层实现类，那你必须设计一套“由调用方传入类加载器”的机制，而不是指望体系自动兼容。线程上下文类加载器就是最通用的那个“传入通道”。

5.3 线程上下文类加载器：一个线程级别的“传球”道具

TCCL的实现简单，但它能玩出的花样不少。每个Thread对象内部都有一个contextClassLoader字段，默认继承创建它的那个线程的TCCL。框架代码只要愿意，随时可以读取和覆盖它：

java复制ClassLoader original = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetClassLoader);
    // 在这里执行需要 targetClassLoader 加载的代码
} finally {
    Thread.currentThread().setContextClassLoader(original);
}

这个模式的精髓在于“在一个代码块里临时切换类加载视角”。很多框架的Class.forName调用就是从当前线程的TCCL里找类的。业务代码里如果发现某个库“突然能加载另一个类加载器管的类”，八成就是它内部玩了这个操作。

但TCCL也有隐患。如果线程池中的线程长期复用，又没有在finally里复位TCCL，那么线程池中的线程可能会一直持有某个类加载器的引用，导致该加载器无法被GC，间接引发类加载器泄漏。处理这类问题，一是规范代码，二是排查时重点关注线程对象的contextClassLoader字段指向谁。

6. 从类加载器视角看JVM调优：日志、Metaspace与模块化

6.1 打开类加载日志：看到类被谁加载了，问题就消失一半

线上遇到“类冲突”“类找不到”之类的问题时，最直接的手段就是打开类加载日志。JDK 8里常用的参数：

bash复制-XX:+TraceClassLoading
-XX:+TraceClassUnloading

JDK 9及以后，这两个参数改名了：

bash复制-Xlog:class+load=info
-Xlog:class+unload=info

日志会打出“哪个类被哪个加载器加载的，从哪个JAR里加载的”，排查类冲突时非常有用。比如你怀疑应用B用到了父容器里某个旧版本的类，打开日志后一眼就能看到com.example.Foo到底是从哪个jar包路径来的，是被哪个加载器加载的。

另一个常用的诊断参数是-verbose:class，它能打印类似信息，而且兼容性很好。我自己的习惯是排查类问题时，先看加载日志，再看堆快照，这两个手段能覆盖绝大多数类加载器相关故障。

6.2 用MAT定位类加载器内存泄漏的完整思路

如果怀疑Metaspace涨得异常，类加载器泄漏的可能性极高。排查步骤我一般是这样做的：

用jmap -dump:format=b,file=heap.bin <pid>拿一版堆快照。
用MAT打开，在Histogram里搜java.lang.ClassLoader，看实例数量和Retained Size。
如果发现某种类加载器的实例数量异常多（比如十几个几十个WebAppClassLoader），右键看“Path to GC Roots”——排查到底谁强引用着它们。
顺着引用链找到Holder，基本就定位到肇事代码了。

这里有个关键认知：类加载器泄漏的根因，往往不是类加载器本身，而是某些长生命周期对象“攥着”它不放。常见大户包括：

静态集合缓存了类加载器或用它做key。
线程池线程的TCCL被改成特定类加载器后没复位。
JNI全局引用、监控Agent、日志框架的上下文残留。

只要把这些外部强引用断开，Metaspace就能自动被回收，不需要手动“卸载类”。这也是为什么类加载器相关的调优，重点从来不是急着改JVM参数，而是先看清楚“谁在引用谁”。

6.3 Java 9+模块化改变了什么：ExtClassLoader退场，委派逻辑微调

Java 9引入模块化系统（JPMS）后，类加载器的面貌和JDK 8差别不小：

ExtClassLoader没有了，取而代之的是PlatformClassLoader。
核心类不再从rt.jar加载，而是从模块运行时镜像里按模块加载。
AppClassLoader的名字变成了ApplicationClassLoader，创建入口改为jdk.internal.loader.ClassLoaders。
委派逻辑由于模块化有了微调，但双亲委派的总体结构依然保留。

模块化之后，一个典型的坑是“可读性”问题。JDK 8里只要类在classpath上，加载器可见性满足基本条件就能加载；JDK 9之后，类能否被加载还要看模块是否被“require”，模块描述符里没声明依赖，编译期可能没事，运行期直接IllegalAccessError或NoClassDefFoundError。所以排查这类问题时，别只盯着类加载器，模块图也要看一眼。

另外说一句容易被热搜词带偏的：-XX:CompileThreshold、G1收集器参数这类调优项，和类加载器几乎没有直接关系。它们管的是JIT编译阈值、垃圾回收行为，不要混在一起讨论。类加载器对应的调优手段更多是“日志+堆栈+堆快照”，而不是堆大小参数。

如果让我总结一个最实用的经验：类加载器这套机制，平时看起来抽象，但线上问题一出现就非常具体。遇到任何“类冲突、类型转换异常、Metaspace异常增长”的问题，先别慌着调参，先确认三件事——类是从哪来的、被哪个加载器加载的、谁还强引用着这个加载器。这三件事查清楚了，大部分问题已经解决一半。剩下的，就是像第4章说的那样，理解C++层那个“看不见的Bootstrap”在整个体系里的分量，这样才能在架构设计时真正把类加载器的隔离和互通边界想清楚。