面试考察点

  • 是否理解先委派父加载器、失败后自身加载的流程。
  • 能否说明类的身份由类名和加载器共同决定。
  • 是否知道 SPI、热部署与插件隔离为何需要不同策略。

核心答案

典型双亲委派中，类加载请求先交给父加载器，父加载器无法完成时子加载器才尝试。它避免核心类被应用重复定义，并让不同模块共享基础类型。这里的“父”是委派关系，不一定是 Java 对象继承关系。

同名类由不同类加载器加载后属于不同类型，强转可能出现看似奇怪的 ClassCastException。

核心价值

委派使 java.lang.String 等核心类型由受信任加载器统一定义，保证类型唯一性和安全边界，也减少重复加载基础依赖。

常见加载器层次

现代 JDK 的具体实现随版本变化，但概念上可区分：Bootstrap 加载 Java 核心模块，Platform 加载平台模块，Application 加载应用 classpath/module-path，框架还可能创建自定义加载器加载插件、热部署应用或隔离依赖。不要把“父加载器”机械理解为 Java 对象字段的父子继承，Bootstrap 在 Java 层通常用 null 表示。

loadClass 的典型流程

  1. 先检查当前加载器是否已经定义过该类，避免重复定义。
  2. 把请求委派给父加载器。
  3. 父加载器找不到时，当前加载器调用 findClass 查找字节并定义。
  4. 需要时再解析并链接引用。

自定义加载器通常重写 findClass，而不是粗暴重写 loadClass。只有明确需要子优先隔离时，才谨慎调整委派顺序，并保留核心 JDK、共享 API 的父优先规则。

类型身份示例

Class<?> a = loaderA.loadClass("com.example.Plugin");
Class<?> b = loaderB.loadClass("com.example.Plugin");

System.out.println(a == b); // false

即使 class 文件字节完全相同，a 和 b 仍是两个类型。把 loaderA 的实例强转为 loaderB 看到的 Plugin 会失败；插件系统必须把双方共享的 SPI 接口放到共同父加载器，避免接口本身被加载两份。

为什么 SPI 需要上下文加载器

JDBC Driver、ServiceLoader 等场景中，框架接口可能由父加载器加载，具体实现位于应用加载器可见范围。严格父优先时，父加载器无法反向看到子加载器的实现。线程上下文类加载器提供一条受控“反向委派”通道，让框架按当前应用上下文发现实现。

使用线程池时要注意上下文类加载器的设置与恢复，否则可能加载错误应用的资源，或让旧应用加载器被线程长期引用。

热部署的泄漏案例

应用服务器重新部署时创建新加载器。若旧应用把对象注册进 JVM 全局单例、JDBC 驱动、Timer 线程、ThreadLocal 或第三方静态缓存，旧加载器始终可达，所有旧类元数据和静态对象都无法回收，最终出现 Metaspace OOM。治理关键是停止线程、注销回调、清理 ThreadLocal 和关闭资源，而不是只增加元空间。

特殊场景

JDBC 等 SPI 的接口由上层加载器加载，实现却在应用类路径中，线程上下文类加载器可让基础代码反向发现实现。插件、应用服务器和热部署常采用子优先或隔离加载器，但要明确共享 API 的加载边界。

常见误区

“打破双亲委派”并不等于完全不委派，成熟实现通常仍对 JDK 和共享 API 采用父优先，只对子应用依赖使用隔离策略。类无法卸载时还要检查加载器是否被线程、缓存或 ThreadLocal 引用。

高频追问与参考回答

追问：如何判断两个 Class 是否相同？

不仅看全限定名，还要看定义它们的类加载器；只有名称和定义加载器都相同，JVM 才认为是同一个运行时类型。

追问：双亲委派能完全防止恶意类吗？

它保护核心名称不被普通应用加载器替换，但完整安全还依赖模块边界、代码来源、权限和输入控制。不能把加载器策略当万能沙箱。

追问：为什么 ClassCastException 中类名看起来完全一样？

异常信息常只显示全限定名，隐藏了加载器差异。打印 getClassLoader()、模块和 CodeSource 能定位是否发生重复加载。

追问：自定义加载器加载的资源如何排查？

记录资源 URL、加载器链和定义来源，必要时用 -verbose:class 或 JFR 类加载事件。不要只依赖 IDE classpath 推断运行时可见性。

总结

双亲委派解决核心类型统一和复用，特殊加载策略解决实现发现与依赖隔离，二者是按边界组合而不是非此即彼。

机制全景图

下面把「双亲委派模型是什么？为什么要打破它？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。

flowchart LR
    A["收到类名请求"]
    A --> B["检查已加载缓存"]
    B --> C["委派父加载器"]
    C --> D["父级无法找到"]
    D --> E["当前加载器定义类"]

完整链路：从输入到结果

沿着「收到类名请求 → 检查已加载缓存 → 委派父加载器 → 父级无法找到 → 当前加载器定义类」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。

1. 收到类名请求

loadClass 先检查 findLoadedClass，避免同一加载器重复定义同名类。

2. 检查已加载缓存

父加载器优先使 JDK 核心类型不容易被应用代码替换，形成基本安全与一致性边界。

3. 委派父加载器

委派链逐级向 Bootstrap 等上层查找，父级可见不代表父级能看见子加载器类。

4. 父级无法找到

父级找不到时子加载器才执行 findClass，从自己的路径、插件包或网络来源读取字节。

5. 当前加载器定义类

类型身份由类名与定义它的类加载器共同决定，强转失败常来自两个加载器各自定义了同名类。

源码与实现定位

入口 阅读重点
ClassLoader#loadClass findLoaded→parent→findClass
jcmd VM.classloader_stats 加载器数量与 Metaspace

源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。

参数配置与可复现实验

java -Xlog:class+load=info,class+unload=info:file=loaders.log -jar app.jar

加载两份同名接口并打印 class.getClassLoader，复现强转失败；卸载插件后强制完整 GC 观察 unload。

验证步骤与预期结果

1. 固定输入和基线

先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「同名类加载器数」为主基线，记录值应满足「共享 API 为 1」；同时保存 类加载器实例数、同名类来源，使后续变化能够回到同一时间轴比较。

2. 从实现入口确认路径

在「ClassLoader#loadClass」确认请求确实进入「findLoaded→parent→findClass」对应的实现，再沿「jcmd VM.classloader_stats」观察「加载器数量与 Metaspace」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。

3. 注入本文特有的失败模式

优先复现「线程上下文类加载器未恢复导致泄漏」，并把单一变量逐级放大，直到「同名类加载器数」越过「>1」。随后再分别验证「插件重复打包共享接口」和「自定义加载器持有缓存无法卸载」，三类故障分开执行，避免多个变量同时变化而无法归因。

4. 执行止损和根因修复

第一轮只应用「共享 API 只由父加载器定义」，确认它能控制影响范围；第二轮应用「恢复线程上下文加载器」，验证核心链路恢复；最后落实「注销 Driver/线程/缓存引用」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。

5. 通过退出条件

实验只有同时满足三项才算通过：「同名类加载器数」回到「共享 API 为 1」、「旧插件加载器」回到「卸载后归零」、「Metaspace 基线」回到「重载后回落」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。

量化基线

指标 样例基线/口径 风险线 结论
同名类加载器数 共享 API 为 1 >1 排除重复依赖
旧插件加载器 卸载后归零 持续累积 查 GC Root
Metaspace 基线 重载后回落 阶梯上涨 加载器泄漏

这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。

事故复盘：插件接口明明同名却无法强转

插件包把宿主 API 也打进自身依赖，子加载器定义了第二份接口。实现类实现的是插件加载器版本，宿主看到的是父加载器版本，因此 ClassCastException。把共享 API 只放父加载器并在打包时排除后恢复。

失败模式 首要证据 第一处置动作
线程上下文类加载器未恢复导致泄漏 类加载器实例数 共享 API 只由父加载器定义
插件重复打包共享接口 同名类来源 恢复线程上下文加载器
自定义加载器持有缓存无法卸载 Metaspace 与卸载数 注销 Driver/线程/缓存引用

发布与回滚检查点

  • 发布前：确认「ClassLoader#loadClass」对应实现和上述配置在目标版本仍然有效，并保存「同名类加载器数」基线。
  • 灰度中：同时观察 类加载器实例数、同名类来源、Metaspace 与卸载数；任一指标越过表中风险线，就停止继续扩量。
  • 回滚时：先执行「共享 API 只由父加载器定义」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
  • 发布后：至少覆盖一个完整峰值周期，确认「线程上下文类加载器未恢复导致泄漏」没有再次出现，才关闭变更观察窗口。

方案对比与选型

方案 更适合的场景 主要收益 代价与边界
父优先 普通应用与共享 API 核心类一致、安全边界清晰 依赖冲突隔离能力有限
子优先 插件或容器需隔离依赖版本 应用可携带独立版本 必须保护 JDK 与共享接口包
模块层/独立进程 强隔离与明确导出 边界清楚、卸载更可控 部署和通信成本更高

选型至少带上 堆与非堆容量、对象分配速率、存活率和停顿目标，并用上面的量化基线验证；未知数据应明确为待测假设。

设计边界与工程取舍

双亲委派是常用实现约定而非 JVM 强制算法；打破它时必须明确哪些包父优先、哪些子优先，以及卸载和安全边界。

工程落地遵循：以可观测证据驱动参数调整，避免脱离业务负载套用参数模板。回答时直接引用「ClassLoader#loadClass」、配置实验和事故数据，比复述固定模板更有说服力。