类加载与双亲委派：先问上级，核心类就只有一份；SPI 要反着找，就得借线程手里的加载器

缺的是一条规矩，让同一个名字的类在需要共享的范围内只被定义一次，并且核心类永远由最上层定义。双亲委派就是这条规矩。不懂这一点的典型误用：以为“类名一样就是同一个类”。开了 Spring Boot devtools 热重启，或者把同一个 jar 同时放进 Tomcat 的 lib/ 和应用的 WEB-INF/lib，看到 X cannot be cast to X 就一头雾水。

选择规则：普通应用不用选，用默认的父优先；需要“同一个 JVM 里多个应用各用各的版本”时用子优先或网状；需要“框架定义接口、业务提供实现”时用 SPI，它离不开 TCCL。本页学父优先，以及 SPI 和 Tomcat 这两种“打破”。

④-1 一个类的一生：加载器只管第一步

⑤ 的 WhoLoads 里，Order 的 static 块在“准备 new Order”之后才打印，-Xlog:class+load 里那一行也排在它前面一点：加载和初始化都推迟到第一次真正用到。初始化失败时（static 块抛异常），这个类会被标成错误状态，之后每次用都报 NoClassDefFoundError: Could not initialize class，见 ⑥ 坑 4。

④-2 三层加载器，和 loadClass 的十几行

protected Class<?> loadClass(String name, boolean resolve) {
  synchronized (getClassLoadingLock(name)) {   // 同名并发加载只放一个
    Class<?> c = findLoadedClass(name);        // 1. 我加载过吗
    if (c == null) {
      try {
        if (parent != null)
          c = parent.loadClass(name, false);  // 2. 先问上级
        else
          c = findBootstrapClassOrNull(name);   // 顶上是启动类加载器
      } catch (ClassNotFoundException e) { }
      if (c == null)
        c = findClass(name);                 // 3. 都没有，才自己找
    }
    if (resolve) resolveClass(c);
    return c;
  }
}

自定义加载器只需要重写 findClass：去哪找字节、然后 defineClass。要“打破”委派，就得重写 loadClass 本身，Tomcat 就是这么做的。JDK 9 以后三个内置加载器另有一套 BuiltinClassLoader.loadClassOrNull：先查这个包属于哪个模块，属于模块就直接交给那个模块的加载器，不在模块里（classpath 上的类）才走上面的父优先。效果一样，少问几层。

④-3 委派走一遍先猜由谁定义，再一步一步看

步骤照 JDK 17 的 ClassLoader.loadClass、BuiltinClassLoader.loadClassOrNull 和 Tomcat 文档里 webapp 加载器的查找顺序编排，模拟逻辑在 node 里跑过；每个加载器“地盘里有什么”是这个场景的设定。

④-4 类的身份：名字 + 定义它的加载器

这条规则是本页一半坑的根源。双亲委派保证的是：只要请求都先往上走，同一个名字在这条链上只会被一个加载器定义。一旦有两个加载器都绕开上级、自己定义了同名类，就是两个类。

④-5 为什么非得先问上级

决定胜负的约束：核心类必须全 JVM 唯一、不可替换，而 JVM 判断“是不是同一个类”只看名字和定义它的加载器。在这两条下面，让请求一律先往上走，是最简单的能保证唯一的办法。它的代价也由此而来：请求只往上走，上层的代码就看不见下层的类。

④-6 SPI 为什么要打破：接口在上面，实现在下面

Tomcat 是另一种打破：webapp 加载器重写了 loadClass，JDK 的类先交给上层，其余的先找 WEB-INF，找不到才问上级。目的是让每个应用用自己的依赖版本，热部署时整个加载器扔掉重建。这两种打破在实验台里都能走一遍。

Order.class.getClassLoader();                         // 谁定义了它；启动类加载器返回 null
Class.forName("labs.trade.Order");                    // 用调用方的加载器，加载并初始化
Class.forName("labs.trade.Order", false, loader);     // 指定加载器，不初始化
loader.loadClass("labs.trade.Order");                 // 走委派，只加载不初始化
Thread.currentThread().getContextClassLoader();       // TCCL，框架加载“用户的类”时用它
ServiceLoader.load(PaymentChannel.class);             // 读 META-INF/services/接口全名，按 TCCL 加载实现

# src/main/resources/META-INF/services/labs.jvm.jvm_classloading.spi.PaymentChannel
labs.jvm.jvm_classloading.channel.MockPay

cd study-labs/java && JAVA_HOME=/usr/lib/jvm/java-17-openjdk-arm64 mvn -q -pl jvm/jvm-classloading compile
cd jvm/jvm-classloading            # 实验按相对路径 target/classes 找类，要在这里运行
J=/usr/lib/jvm/java-17-openjdk-arm64/bin/java; M=labs.jvm.jvm_classloading
$J -Xlog:class+load -cp target/classes $M.WhoLoads | grep -E "Order|DriverManager|─"
$J -cp target/classes $M.TwoOrders
$J -cp target/classes $M.SpiDemo

1. 谁加载了谁

加载器链（从下往上）：
  jdk.internal.loader.ClassLoaders$AppClassLoader@30946e09
  jdk.internal.loader.ClassLoaders$PlatformClassLoader@5f712fd4
  null = 启动类加载器（C++ 实现，Java 里拿不到对象）
  String                     → null
  DriverManager              → …PlatformClassLoader@5f712fd4
[class,load] java.sql.DriverManager source: jrt:/java.sql
准备 new Order ……
[class,load] labs.jvm.jvm_classloading.Order source: file:/…/target/classes/   # 第一次 new 时才加载
  [Order 的 static 块执行了：类初始化，只会有一次] loader=…AppClassLoader@30946e09
  Order                      → …AppClassLoader@30946e09
当前线程的上下文类加载器（TCCL）：…AppClassLoader@30946e09

2. 两个 Order

URL classes = new File("target/classes").toURI().toURL();
// parent = null：只问启动类加载器，不问 app，相当于“各找各的”
URLClassLoader a = new URLClassLoader(new URL[]{classes}, null);
URLClassLoader b = new URLClassLoader(new URL[]{classes}, null);
Class<?> ca = a.loadClass("labs.jvm.jvm_classloading.Order");
Class<?> cb = b.loadClass("labs.jvm.jvm_classloading.Order");
Object fromA = ca.getConstructor(long.class, int.class).newInstance(1024L, 2);
Order o = (Order) fromA;     // 这里的 Order 是 app 定义的那个

ca.getName().equals(cb.getName()) = true
ca == cb                           = false
ca == Order.class                  = false
  [Order 的 static 块执行了：类初始化，只会有一次] loader=java.net.URLClassLoader@251a69d7   # “只一次”是对每个类而言：这是另一个类
fromA instanceof Order             = false
ClassCastException: class labs.jvm.jvm_classloading.Order cannot be cast to class labs.jvm.jvm_classloading.Order
 (labs.jvm.jvm_classloading.Order is in unnamed module of loader java.net.URLClassLoader @251a69d7;
  labs.jvm.jvm_classloading.Order is in unnamed module of loader 'app')

JDK 17 上这条异常信息会把两边的加载器都写出来。看到 X cannot be cast to X，先看括号里的两个 loader。

3. 支付渠道 SPI：框架在上，实现在下

// 两层：framework 只定义 spi 包（接口 PaymentChannel、框架代码 ChannelRegistry），看不见服务文件
//      app = URLClassLoader(target/classes)，parent = framework，能看到实现 channel.MockPay
FrameworkLoader framework = new FrameworkLoader();
Named app      = new Named("app", framework);
Named isolated = new Named("isolated", null);        // 不委派：自己再定义一份接口

// ChannelRegistry 里：
ServiceLoader.load(PaymentChannel.class, ChannelRegistry.class.getClassLoader());  // ① 用自己的
ServiceLoader.load(PaymentChannel.class);                                           // ②③④ 用 TCCL

// 换 TCCL 的写法：用完一定还回去
ClassLoader old = t.getContextClassLoader();
t.setContextClassLoader(cl);
try { … } finally { t.setContextClassLoader(old); }

ChannelRegistry 由谁定义：framework
MockPay        由谁定义：app
① 框架用自己的加载器找实现：0 个 []
② TCCL = framework → 0 个 []
③ TCCL = app        → 1 个 [MockPay(loader=app)]
④ TCCL = isolated   → ServiceConfigurationError: labs.jvm.jvm_classloading.spi.PaymentChannel: labs.jvm.jvm_classloading.channel.MockPay not a subtype

到这里已经能交差了：能说出一个类由谁加载、为什么会 X cannot be cast to X、SPI 找不到实现时先查 TCCL。已知还没处理的细节：加载器泄漏把元空间撑爆（坑 2），线程池里 TCCL 不对（坑 3），初始化失败后的 NoClassDefFoundError（坑 4），依赖冲突（坑 5）。

版本差异

下一圈

• Tomcat WebappClassLoaderBase.loadClass 源码：子优先的完整顺序，以及停应用时的泄漏检测
• Spring Boot 可执行 jar 的 LaunchedURLClassLoader（3.2 起叫 LaunchedClassLoader）：jar 套 jar 是怎么读出来的
• Java agent 与 Instrumentation：在类加载时改字节码（Arthas、SkyWalking 的原理）
• 隐藏类（JDK 15，JEP 371）：lambda 生成的类改成隐藏类以后，为什么可以单独卸载
• JIT、逃逸分析（全景第 2 站，下一个知识点）：类加载完以后，代码是怎么变快的
• JVM 故障排查（第 9 站）：用 VM.classloader_stats、堆转储把坑 2 查到具体引用链

自测