Outaink's Blog

Java 类加载器

10分钟阅读

类加载器的双亲委派机制 (Parents Delegation Model)。

为了让它更生动，我们换个场景。想象一下，我们不再谈论工厂，而是进入一个庞大的**“全球 IT 集团”**。这个集团等级森严，分工明确，而类加载器就是负责为集团招聘和管理各类技术人才（加载 Class 文件）的 HR 部门。

一、 什么是类加载器 (ClassLoader)？

首先，ClassLoader 是什么？

它是 JVM 的一个核心子系统，负责在运行时根据类的全限定名（例如 java.lang.String）动态地从硬盘、网络或其他来源加载对应的二进制字节流（.class 文件），并将其转换为 java.lang.Class 的一个实例。

集团比喻：

ClassLoader 就是集团里的 HR 部门。当项目（你的代码）需要一位名叫 “String” 的专家时，HR 部门就负责去人才市场（硬盘/网络）找到这位专家的简历（.class 文件），核实其身份，然后将其引入公司，成为一名可以随时调遣的正式员工 (Class 对象)。

二、 集团的 HR 体系：三位核心 HR 经理

在这个全球 IT 集团中，HR 体系不是扁平的，而是有层级的。主要有三位核心的 HR 经理（类加载器），他们各司其职，形成了管理上的父子关系（注意：这里是组合关系，不是继承）。

  1. 启动类加载器 (Bootstrap ClassLoader) - “集团创始人/CEO”
    • 职责：负责招聘集团最最核心、最基础的技术专家。这些专家是集团赖以生存的基石。
    • 加载内容：<JAVA_HOME>/lib 目录下的核心类库，比如 rt.jar 里的 java.lang.String, java.util.ArrayList 等。
    • 特殊地位：这位“创始人”非常神秘，他由 C++ 实现，并非 Java 对象，所以在 Java 代码中你无法直接获取到他（获取其引用会返回 null）。他是所有 HR 的顶层领导。
  2. 扩展类加载器 (Extension ClassLoader / Platform ClassLoader) - *“总部核心技术总监”
    • 职责：负责招聘集团的一些通用性、扩展性的技术专家，为各个业务线提供支持
    • 加载内容：<JAVA_HOME>/lib/ext 目录下的扩展 Jar 包
    • 管理关系：他的上级领导是“创始人”（Bootstrap ClassLoader）
  3. 应用程序类加载器 (Application ClassLoader / System ClassLoader) - “区域/项目 HR 经理”
    • 职责：负责招聘项目自身业务代码中需要的技术人才，也就是我们自己编写的那些类
    • 加载内容：我们程序的 classpath 下的所有类。我们平时开发中接触最多的就是他
    • 管理关系：他的上级领导是“总部技术总监”（Extension ClassLoader）。他也是我们默认使用的类加载器。

集团的组织架构图：

      Bootstrap ClassLoader (创始人 - C++)
             ^
             | (上级)
             |
   Extension ClassLoader (总部技术总监)
             ^
             | (上级)
             |
Application ClassLoader (项目 HR 经理)
             ^
             | (上级)
             |
     Custom ClassLoader (自定义 HR - 如果有的话)

三、 核心机制：双亲委派模型的工作流程

现在，重头戏来了。当项目经理（你的代码）向他直属的“项目 HR 经理”（Application ClassLoader）提出一个招聘需求时：“我需要一位名叫 com.mycompany.MyClass 的专家”，这位 HR 经理并不会立刻亲自去人才市场（classpath）寻找。

他会遵循一套严谨的 “向上委派，向下查找” 的汇报流程，这就是双亲委派机制。

招聘流程详解：

  1. 提交申请：项目组需要 com.mycompany.MyClass。招聘申请首先被递交到 Application ClassLoader（项目 HR 经理）。
  2. 向上委派 (Delegate Up)：
    • 项目 HR 不会立即行动。他会先毕恭毕敬地问他的上级 Extension ClassLoader（总部技术总监）：“领导，这个 com.mycompany.MyClass 您那边能搞定吗？您见过吗？”
    • 总部技术总监也不会立即行动。他同样会先请示他的上级 Bootstrap ClassLoader（创始人）：“老板，这个 com.mycompany.MyClass 是不是我们集团最核心的元老级专家？您认识吗？”
  3. 高层尝试处理 (Attempt to Load)：
    • 请求最终到达了顶层的 Bootstrap ClassLoader。这位“创始人”会审视这个需求，并在自己的管辖范围（核心库 <JAVA_HOME>/lib）内查找。他发现：“嗯，不认识，我这里没有叫这个名字的核心专家。”
    • 于是，他告诉下属 Extension ClassLoader：“我搞不定，你来处理吧。”
    • Extension ClassLoader 收到回复后，开始在自己的管辖范围（扩展库 <JAVA_HOME>/lib/ext）内查找。他也发现：“我这里也没有这个人。”
    • 于是，他告诉下属 Application ClassLoader：“我也搞不定，还是你亲自出马吧。”
  4. 向下查找与执行 (Load Down)：
    • 直到此时，Application ClassLoader 才确认：“看来我的上级们都解决不了这个需求，这个人应该是我项目自己的人。”
    • 于是，他才开始在自己的管辖范围（classpath）内进行搜索。他找到了 com/mycompany/MyClass.class 文件，成功加载了它，完成了招聘任务。 如果招聘的是 java.lang.String 呢？

流程会稍有不同：

  1. 申请逐级上报到 Bootstrap ClassLoader
  2. Bootstrap ClassLoader 一看：“java.lang.String？这不是我们集团的首席架构师吗！我当然认识。”
  3. 他立刻从自己的核心人才库（rt.jar）中找到了这位专家并加载了他
  4. 招聘成功！请求直接在顶层就被处理完毕，根本不会再向下传递给 Extension 或 Application ClassLoader

四、 为什么要设计这么“绕”的机制？

这个看似繁琐的流程，其实蕴含着两大核心优势：

  1. 避免类的重复加载 (Ensures Uniqueness)
    • 核心思想：一个类，无论被哪个类加载器加载，最终都应该是由同一个加载器加载的、唯一的 Class 对象
    • 机制保障：通过向上委派，保证了所有加载请求最终都会优先尝试由上层的加载器来完成。比如 java.lang.String，无论你的代码在哪里尝试加载它，最终都会被委派到 Bootstrap ClassLoader 加载。这就确保了 JVM 中永远只有一份 String.class 的实例
    • 比喻：确保了集团的“首席架构师 (String)”永远只有一位，并且是由“创始人 (Bootstrap)”亲自认证的，不会出现项目A招一个“首席架构师”，项目B又招一个同名的“首席架构师”，导致内部混乱
  2. 保证核心类库的安全性 (Ensures Security)
    • 核心思想：防止核心 API 类被恶意篡改。
    • 机制保障：假设一个黑客自己写了一个恶意的 java.lang.String 类，并把它放在 classpath 中，企图替换掉 JDK 原生的 String。在双亲委派机制下，当 JVM 尝试加载 java.lang.String 时，请求会一直被委派到顶层的 Bootstrap ClassLoader。Bootstrap ClassLoader 只会加载 JDK 核心库中的那个官方 String 类，而黑客放在 classpath 下的那个恶意 String 类，根本没有机会被加载。
    • 比喻：防止了外部人员伪造一个“首席架构师”，并通过项目 HR 的招聘混入集团高层。所有核心职位的招聘请求，最终都会被创始人拦下并亲自处理，确保了管理团队的纯洁和安全。

总结

双亲委派机制是 Java 类加载器架构的精髓，它通过一种“等级分明、层层上报”的机制，优雅地解决了类的唯一性和安全性问题，是 Java 平台能够长久保持稳定和安全的重要基石。

关系图谱

反向链接