Java类加载器有哪些？ClassLoader体系全解析

本文深入解析了Java类加载器的完整体系与演进变迁，从JVM底层的C++实现的启动类加载器（仅加载核心类且Java层不可见），到JDK9模块化后被PlatformClassLoader取代的扩展类加载器，再到日常开发中承担主力加载任务却存在路径限制的AppClassLoader，最后阐明自定义加载器必须严格遵循双亲委派机制、仅重写findClass而非loadClass的关键实践准则；文章不仅厘清常见误区（如bootstrap加载器无法加载任意lib目录下的JAR、JDK9+不再支持ext机制、AppClassLoader不支持嵌套JAR等），更直击运行时痛点——不同加载器加载的相同字节码会生成互不兼容的Class对象，为框架开发、热部署、模块隔离等高阶场景提供不可替代的底层认知基础。

启动类加载器（Bootstrap ClassLoader）到底能加载哪些类？

它只加载 JVM 自身信任的核心类，比如 java.lang.String、java.util.ArrayList 这些来自 rt.jar（JDK 9+ 后为 modules）的类。关键点在于：它由 C++ 实现，**Java 层完全无法获取其引用**——调用 String.class.getClassLoader() 返回 null，不是 bug，是设计如此。

常见误区是以为把自定义 JAR 放进 $JAVA_HOME/jre/lib 就能被它加载，实际不会：它只认特定名称（如 rt.jar、jsse.jar）和路径，且不扫描子目录。可通过 Launcher.getBootstrapClassPath().getURLs() 查看真实加载路径。

扩展类加载器（Extension ClassLoader）在 JDK 9+ 还存在吗？

不存在了。JDK 9 引入模块系统（JPMS）后，ExtensionClassLoader 被废弃，其职责由 PlatformClassLoader 接管，负责加载 java.* 和 javax.* 等平台模块（如 java.xml、java.logging）。但注意：PlatformClassLoader **不加载 rt.jar，也不加载用户扩展 JAR**——那些本该放 /lib/ext 的老式扩展包，在 JDK 9+ 中必须转为模块或改用其他方式集成。

实操建议：

• 不要在 JDK 9+ 项目中依赖 java.ext.dirs 系统属性；
• 若需兼容旧扩展机制，应改用自定义类加载器 + URLClassLoader 显式加载；
• 通过 ClassLoader.getSystemClassLoader().getParent() 在 JDK 8 可得 ExtClassLoader，在 JDK 9+ 则返回 PlatformClassLoader。

为什么 AppClassLoader 是绝大多数场景的默认加载器？

因为它是 ClassLoader.getSystemClassLoader() 返回的对象，也是每个线程默认的 contextClassLoader（除非显式设置）。你写的主类、Maven 依赖的 JAR、IDE 的 output 目录，全靠它加载。

但它有明确边界：只查 java.class.path（即 -cp 或 CLASSPATH），**不自动扫描子目录或嵌套 JAR 内的 classpath**。这也是 Spring Boot 的 fat-jar 必须内置 LaunchedURLClassLoader 的原因——标准 AppClassLoader 无法读取 BOOT-INF/classes 下的类。

容易踩的坑：

• 在 Web 容器（如 Tomcat）里，AppClassLoader 不负责加载 WEB-INF/lib 中的类，那是 WebappClassLoader 干的；
• 调用 Thread.currentThread().getContextClassLoader() 获取的未必是 AppClassLoader，尤其在框架（如 Spring、Log4j2）中可能已被重置；
• Class.forName("xxx") 默认使用当前类的类加载器，而非 AppClassLoader，这点常被忽略。

自定义类加载器真要继承 ClassLoader 并重写 findClass 吗？

是的，但必须绕开 loadClass——这是双亲委派的入口，直接重写会破坏安全模型。正确姿势是：继承 ClassLoader，只重写 findClass(String name)，在里面读取字节码（文件/网络/解密后）、调用 defineClass，其余流程交给父类的 loadClass 处理。

典型错误写法：public Class> loadClass(String name) { return findClass(name); } ——这彻底跳过了双亲委派，连 Object 都可能加载失败。

真正需要打破委派的场景极少，比如：

• OSGi 模块间需要隔离同名类；
• 热部署时用新加载器加载更新后的 class，避免旧实例残留；
• 从加密 JAR 中动态解密加载（此时 findClass 内部做 AES 解密再 defineClass）。

最后提醒：同一个 .class 文件，被不同类加载器加载后，得到的是 JVM 中两个完全无关的 Class 对象——哪怕它们字节码一模一样，instanceof 和强制转型都会失败。这是隔离性的代价，也是最容易被忽略的运行时陷阱。

好了，本文到此结束，带大家了解了《Java类加载器有哪些？ClassLoader体系全解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！