Java 类路径加载顺序解析

Java类路径加载顺序是理解JVM如何定位和加载类的核心机制，它严格遵循“启动类加载器→扩展类加载器→应用类加载器”的层级结构，并以双亲委派模型为根本原则：每个加载器优先委托父加载器尝试加载，仅当父加载失败时才自行查找；启动加载器负责JAVA_HOME/jre/lib下的核心类（如rt.jar），扩展加载器（JDK9+已废弃）扫描lib/ext，而应用加载器则按-cp > CLASSPATH > 当前目录的优先级从左到右搜索用户类——这一看似简单的顺序，实则直接决定了NoClassDefFoundError、版本冲突或覆盖失效等常见问题的根本原因：真正起作用的不是你“加了什么”，而是“谁先看到、谁有权加载”。

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学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！