Java类路径加载顺序详解

Java 类路径加载顺序是理解 JVM 类加载行为的核心——它严格遵循启动类加载器→扩展类加载器→应用类加载器的层级结构，并以双亲委派模型为运行准则：父加载器优先尝试加载，仅当失败时才由子加载器介入；启动加载器固守 JAVA_HOME/jre/lib 下的核心类（如 rt.jar），扩展加载器在 JDK 9+ 已被模块系统取代，而应用加载器则按 -cp > CLASSPATH > 当前目录 的优先级从左到右扫描用户类路径，首次匹配即止。掌握这一机制，不仅能精准诊断 NoClassDefFoundError、ClassNotFoundException 和诡异的版本覆盖问题，更能从根本上避免因类加载冲突导致的运行时异常与类型不一致陷阱。

Java 程序运行时，类路径（Classpath）决定了 JVM 从哪里加载类文件。搜索顺序不是随意的，而是严格遵循规则——理解它能帮你快速定位 NoClassDefFoundError、ClassNotFoundException 或版本冲突问题。

启动类加载器（Bootstrap ClassLoader）优先加载核心类

这是最顶层的类加载器，由 C++ 实现，不继承自 java.lang.ClassLoader。它负责加载 JAVA_HOME/jre/lib 下的关键资源：

• rt.jar（Java 8 及之前，含 java.lang.*、java.util.* 等所有标准 API）
• resources.jar、charsets.jar、ext/*.jar（部分扩展，但注意：JDK 9+ 中 ext 机制已被模块系统替代）
• 这些路径由 JVM 内置决定，无法通过 -cp 或 CLASSPATH 覆盖；即使你在 classpath 中放了同名的 String.class，也不会被加载

扩展类加载器（Extension ClassLoader）次之，加载 lib/ext

它由 sun.misc.Launcher$ExtClassLoader 实现，父加载器是 Bootstrap。默认扫描：

• JAVA_HOME/jre/lib/ext 目录下的所有 JAR 文件（Java 8 及更早）
• 可通过 -Djava.ext.dirs=... 系统属性覆盖该路径（不推荐，易引发兼容性问题）
• 注意：JDK 9 引入模块系统后，ext 机制已废弃；若用 --module-path 启动，则此阶段不生效

应用类加载器（Application ClassLoader）最后加载用户类

也称系统类加载器（sun.misc.Launcher$AppClassLoader），负责加载用户指定的类路径。其搜索顺序为：

• 先检查 -cp（或 -classpath）参数显式指定的路径 —— 这是最常用、最高优先级的用户级控制方式
• 若未指定 -cp，则回退到环境变量 CLASSPATH 的值（Windows/Linux 均有效，但建议避免依赖它，因易受污染）
• 若两者都未设置，则默认使用当前目录（.）
• 路径内多个条目用 :（Linux/macOS）或 ;（Windows）分隔，JVM 从左到右依次查找，找到第一个匹配的类即停止（不会继续向后搜索同名类）

双亲委派模型决定实际加载行为

类加载并非简单按路径顺序“扫描”，而是通过双亲委派（Parent Delegation）机制执行：

• 每个类加载器在接到加载请求时，先委托给父加载器尝试；只有父加载器无法加载（返回 null），才自己查找
• 因此，即使你在 -cp 中放入了 javax.servlet.HttpServlet.class，只要它已在 rt.jar 或模块中存在，就不会被你的版本加载
• 打破委派（如自定义类加载器重写 loadClass()）需谨慎，否则可能破坏类型一致性（例如两个 String 类被视为不同类型）

掌握这个顺序，你就知道为什么改了 CLASSPATH 没生效、为什么旧版 JAR 覆盖不了新功能、以及为何 java -cp lib/a.jar:lib/b.jar MyApp 中 a.jar 的同名类总被优先使用。关键不在“加了什么”，而在“谁先看到、谁有权加载”。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java类路径加载顺序详解》文章吧，也可关注golang学习网公众号了解相关技术文章。