最近后台收到好几条留言都是同一个问题面试官问 JVM 类加载机制到底要怎么答才算过关说实话这个问题我在面试别人时也经常问而且基本上一聊就能看出对方是背了八股文还是真的理解过。类加载机制这东西平时写业务代码确实不太会直接碰它但一旦你开始碰框架源码、搞热部署、排查线上ClassNotFoundException你马上就会意识到这块知识根本不是面试题是基本功。今天就把 JVM 类加载机制这条主线完整梳理一遍从类加载的完整生命周期、双亲委派模型的源码逻辑到打破双亲委派的真实场景再到面试高频问题的排查思路全部讲透。如果你正在准备 JVM 面试题或者手头正好有一个类加载相关的诡异问题搞不定这篇值得你花二十分钟好好看完。1. 类加载机制到底在解决什么问题很多人的误区是JVM 类加载机制就是一套“把 .class 文件变成 Class 对象”的流程。这话没错但太表面了。它背后解决的是三个非常实际的问题字节码从哪里来、按什么规则来、加载错了怎么办。1.1 类加载不是简单的一次性读取Java 程序跑起来之前.java源码会先被 javac 编译成.class字节码文件。类加载机制负责的是在程序运行过程中按需把这些字节码读进 JVM 内部转换成 JVM 能识别的Class对象并且完成一系列校验和准备动作。注意一个关键点类加载是懒加载不是全量加载。JVM 不会在启动时把所有类一口气读进来而是运行到哪个类才去加载哪个类。这也是为什么你写了个public class Main启动起来特别快因为真正被加载的类其实不多。这种按需加载的设计直接影响了后面要讲的双亲委派模型——既然不知道程序未来会用到哪些类那加载时就必须有一套动态查找和避免冲突的机制。补充一个细节Java 的“类”和“对象”是两个层面的东西。Class 对象是类元信息的载体存储在 JVM 的方法区元空间而具体的实例对象在堆上。每个类只会被加载一次所以同一个 ClassLoader 加载同一个类得到的Class对象是唯一的。类加载机制这一整套逻辑核心就是保证这个唯一性和安全性。1.2 谁来学、学它的价值在哪如果你是个纯业务开发平时只写 CRUD类加载机制看起来确实离你很远。但只要你做过下面任何一件事你就绕不开它排查线上ClassNotFoundException或NoClassDefFoundError这两个错误如果不理解类加载机制排查起来会非常痛苦。接触过 Tomcat、Spring Boot 这类框架它们内部大量使用自定义 ClassLoader 实现隔离和热部署。写过 JDBC 驱动加载、SPI 扩展点之类的代码会发现默认类加载方式根本加载不到第三方 jar 包里的实现类必须打破双亲委派。面试时被问到 JVM 原理、类加载顺序、OOM 判断这些问题的底层逻辑都指向类加载机制。说白了类加载机制是 JVM 对“类”这个最小运行单元的完整管理策略。不理解它你对 Java 运行时的认知就是残缺的。2. 类的一生从字节码到可用的 Class 对象要理解类加载机制先得把“加载”这件事拆开看。JVM 规范里一个类的生命周期包含七个阶段加载Loading、验证Verification、准备Preparation、解析Resolution、初始化Initialization、使用Using、卸载Unloading。其中前三步加解析统称“连接Linking”。很多人容易混淆的是日常说的“类加载”其实混用了“加载”和“初始化”两个概念。写代码时我们用Class.forName()或new关键字触发的是完整流程但具体到 JVM 内部每一步都有自己的规则和触发时机。2.1 加载Loading查找到定义再生成 Class 对象加载阶段要做的事比较明确通过类的全限定名获取定义此类的二进制字节流把这个字节流所代表的静态存储结构转化为方法区的运行时数据结构最后在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据的访问入口。注意这个阶段的关键在于“获取二进制字节流”的方式非常灵活不一定非要从 class 文件读。网络传输的字节流、动态代理生成的字节码、JSP 编译后的 class 文件、数据库里存的二进制内容都可以作为加载来源。这也是自定义 ClassLoader 能实现很多骚操作的基础。实操中有一个高频概念是“数组类”的加载。数组类本身不通过 ClassLoader 加载而是由 JVM 直接在内存中构造。但数组的元素类型最终还是要靠 ClassLoader 加载所以数组类的加载规则会和元素类型绑定。这个细节比较冷门但面试官如果问数组类加载方式往往就是想看你有没有认真读过源码。2.2 验证与准备安全校验和内存预分配加载完拿到二进制字节流后不能直接用必须先过验证关。验证阶段做的事可以理解成“安检”确保字节流符合 JVM 规范、不会危害 JVM 自身安全。它包括文件格式验证、元数据验证、字节码验证、符号引用验证四个维度。这里我想强调字节码验证它是整个验证阶段最复杂的一环。JVM 会通过数据流分析验证程序的控制流和数据类型是否安全比如操作数栈的类型是否匹配、方法调用是否合法、跳转指令是否指向正确位置等。一旦发现不合法的字节码就会抛出VerifyError。不过现代 JVM 默认开启了分层编译大量验证逻辑实际由解释器在执行时完成所以验证阶段的开销被摊薄了不少。准备阶段是为类变量static 修饰的变量分配内存并设置初始值。注意这里说的是初始值不是代码里写的赋值。比如private static int count 100;准备阶段给 count 赋的值是 0而不是 100。真正赋 100 要等到初始化阶段执行clinit方法时才会发生。但如果变量被final修饰且是编译期常量那准备阶段就会直接赋上准确值这是不少面试题里爱挖的坑。2.3 解析把符号引用换成直接引用解析阶段做的事情是把常量池中的符号引用替换为直接引用。现在你可能有点懵什么是符号引用什么是直接引用。打个比方你在论文里写“第 3.2 节的内容”这就是符号引用它描述了一个目标但没有指向具体位置。而“第 47 页第 12 行的那句话”就是直接引用它直接告诉你去找哪里。Java 类编译后所有的方法调用、字段访问都是符号引用因为这些目标类可能还没有被加载。解析就是把符号引用逐步变成 JVM 可以直接使用的内存地址或句柄。关于解析时机JVM 规范允许在类被加载后立即解析也允许在某个符号引用第一次被使用时才解析这种策略叫“延迟解析”。HotSpot 默认选择的就是延迟解析好处是能减少启动时间。但有一个例外invokedynamic指令的解析时机是特殊的因为它的目标是动态语言支持解析结果会缓存在方法调用点这个细节在面试里被问到的概率不高但碰到了能说出个所以然会很加分。2.4 初始化静态代码终于开始执行初始化阶段是类加载过程的最后一步也是真正开始执行类中定义的 Java 代码的阶段。在这个阶段JVM 会执行clinit方法这个方法由编译期收集所有类变量的赋值动作和静态代码块中的语句合并生成。clinit方法有几个特点值得记住它不是程序主动调用才执行的而是在类首次被“主动使用”时由 JVM 自动触发。如果一个类没有静态变量也没有静态代码块编译后就不会生成clinit方法。clinit的执行是线程安全的。JVM 会保证在多线程环境下对同一个类的初始化只有一个线程执行其他线程必须等待。所以如果你在静态代码块里写了个耗时的初始化操作非常容易成为多线程场景下的性能瓶颈。触发初始化的时机Java 虚拟机的规范里列了六种主动使用场景new创建实例、访问静态字段被 final 修饰的编译期常量除外、调用静态方法、反射调用Class.forName()、初始化子类时父类必须先初始化、程序启动时的主类。把这些记清楚很多“为什么这个类没初始化”的问题就能一眼看穿。3. 双亲委派模型JVM 最经典的“向上请示”机制前面把类的生命周期讲完了接下来是重头戏双亲委派模型。这一节也是面试官最爱深挖的部分因为它考察的不只是记忆而是你对设计意图的理解深度。3.1 双亲委派到底是怎么“委派”的先明确一个概念双亲委派模型里的“双亲”不是两个父类它描述的是一种层级关系。JVM 预置了三种类加载器启动类加载器 Bootstrap ClassLoader、扩展类加载器 Extension ClassLoaderJDK 9 叫 Platform ClassLoader、应用程序类加载器 Application ClassLoader。它们的父子关系是逻辑上的组合关系不是 Java 继承关系。双亲委派的工作流程概括起来就一句话一个类加载器收到类加载请求先不自己尝试加载而是把这个请求交给父加载器去处理父加载器处理不了才轮到子加载器自己动手。这种一层层向上请示的机制保证了类加载的优先级是自上而下的。用代码来表达就是每个自定义类加载器都持有父加载器的引用加载时调loadClass()方法内部先检查类有没有被加载过没有的话就调父类的loadClass()父加载器也没加载过就继续往上直到 Bootstrap ClassLoader。如果所有父加载器都找不到这个类才回到子加载器调用findClass()自己加载。3.2 从源码角度拆解 loadClass() 方法光看概念容易忘直接看 HotSpot 里ClassLoader.loadClass()的源码更直观。核心逻辑大概是这样的protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 1. 先检查类是否已经被当前加载器加载过 Class? c findLoadedClass(name); if (c null) { try { // 2. 有父加载器就交给父加载器 if (parent ! null) { c parent.loadClass(name, false); } else { // 3. 没有父加载器说明是启动类加载器 c findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加载器加载不到忽略等会自己加载 } // 4. 父加载器也没找到调用 findClass 自己加载 if (c null) { c findClass(name); } } if (resolve) { resolveClass(c); } return c; } }你看loadClass的方法是整个双亲委派的核心。默认实现里每个类加载器先尝试让父加载器加载父加载器抛异常了自己才调用findClass()。所以如果你要自定义 ClassLoader正确做法是只重写findClass()不要重写loadClass()。一旦你动了loadClass()就相当于打破了双亲委派模型。这里顺便提一个关于锁的细节。JDK 8 开始loadClass方法内部有一个getClassLoadingLock的同步块它是为了避免同一个类被多个线程同时加载导致重复创建 Class 对象。默认这个锁对象是 ClassLoader 实例本身但如果你的系统里定义了多个不同的 ClassLoader它们各自是独立的锁依然可能出现同一个全限定名被多个加载器加载成两个不同 Class 的情况这就是后面要讲的类隔离问题。3.3 为什么非要用双亲委派三个核心原因面试时只把流程背出来只能拿及格分能讲清楚“为什么这么设计”才能拿高分。我觉得至少要能说出三个层面的原因第一避免类的重复加载。如果没有双亲委派同一个类被不同的加载器加载就会出现两个不同的 Class 对象程序里用instanceof判断时会直接失败因为 JVM 里判断两个类是否相同不仅要看全限定名还要看类加载器是否一致。双亲委派通过统一的向上委派保证了同一个类在全局范围内尽量只有一个加载结果。第二保证 Java 核心库的安全。比如java.lang.String这个类如果让应用加载器随便加载理论上你完全可以自己写一个伪造的 String 类放进 classpath。双亲委派机制保证了对于这些核心类加载请求会一直向上委派到 Bootstrap ClassLoader最终加载的一定是 JDK 自带的那个 String。这样就避免核心 API 被篡改。第三提供一致的类加载环境。所有加载请求都从父加载器开始使得整个类加载体系呈现出一种层级化、有秩序的协作方式也为后面的类隔离、热部署等高级特性提供了稳定的基础。你把这些原因理解透了后面再看 SPI、Tomcat 为什么要打破双亲委派会突然有种豁然开朗的感觉。4. ClassLoader 体系全景图从启动加载器到线程上下文加载器了解了双亲委派之后得把整个 ClassLoader 体系拼完整。这一节我会讲到 JVM 内置的三种类加载器、它们的加载路径以及大量框架里离不开的线程上下文类加载器。4.1 三种内置类加载器各管一段路径先看 JVM 预置的三个类加载器。Bootstrap ClassLoader启动类加载器是最顶层的加载器用 C 实现不继承任何 Java 类。它负责加载 JVM 自身运行所需的核心库也就是JAVA_HOME/lib目录下能被 JVM 识别的类库比如rt.jar、jce.jar。注意JDK 9 之后引入了模块化这些核心库的加载方式有变化但默认仍然由启动类加载器负责。由于它不继承java.lang.ClassLoader在 Java 代码里拿到的引用是 null很多人第一次看到String.class.getClassLoader()返回 null 时会愣一下实际上 null 代表的就是 Bootstrap。Extension ClassLoader在 JDK 8 及以前叫扩展类加载器负责加载JAVA_HOME/lib/ext目录下的类库。JDK 9 模块化之后它变成了 Platform ClassLoader主要负责加载一些平台相关的模块。要注意日常开发中你很少直接和它打交道但面试时如果说错它的加载路径会显得基本功不扎实。Application ClassLoader应用类加载器也叫系统类加载器负责加载 classpath 上所有的类。它是最常用的加载器我们写的业务代码默认全由它加载。它的父加载器是扩展类加载器扩展类加载器的父加载器是启动类加载器。这个层级关系一定要记牢启动类加载器最顶层→ 扩展/平台类加载器 → 应用类加载器 → 自定义类加载器。画出来是个倒树结构加载请求从树叶往树根方向走。4.2 用一个实例看加载器关系看一段简单代码验证一下加载器关系public class ClassLoaderDemo { public static void main(String[] args) { ClassLoader cl ClassLoaderDemo.class.getClassLoader(); System.out.println(cl); // sun.misc.Launcher$AppClassLoader System.out.println(cl.getParent()); // sun.misc.Launcher$ExtClassLoader System.out.println(cl.getParent().getParent()); // null } }运行结果里第一个是 AppClassLoader第二个是 ExtClassLoader第三个是 null。null 不是没有父加载器而是父加载器是 Bootstrap因为它是 C 写的没有对应的 ClassLoader 对象所以向上拿引用时拿到的是 null。实际排查问题的时候这个技巧非常有用。你可以在出问题的类里打点日志打印getClassLoader()快速确认这个类到底被哪个加载器加载了。如果发现全限定名相同但加载器不同两个 Class 必然不相等问题大概率出在类隔离上。4.3 线程上下文类加载器双亲委派的“后门”讲完三种内置加载器必须聊聊“线程上下文类加载器”也就是 Thread Context ClassLoader简称 TCCL。这个东西在框架代码里出场率极高不搞懂它很多框架源码你根本读不下去。默认情况下线程上下文类加载器是应用程序类加载器。它的作用要结合 SPI 机制来理解。以 JDBC 为例java.sql.DriverManager在启动类加载器负责的rt.jar里但它要加载的数据库驱动实现类在应用的 classpath 里。问题是双亲委派模型的加载方向是自下而上而这里需要的方向是自上而下。启动类加载器根本没有能力加载应用 classpath 里的 MySQL 驱动。怎么办JDK 搞了个“逆向”方案在DriverManager初始化时它不去直接尝试加载实现类而是拿到当前线程的上下文类加载器用这个加载器去加载驱动。线程上下文类加载器本质上是给父加载器一个绕过自身加载路径限制的“后门”允许高层加载器委托给下层加载器去完成加载。这类设计还有一个典型场景就是 Spring。Spring 的类加载体系非常庞大很多扩展点都需要在运行时动态加载用户提供的类底层靠的就是 TCCL。所以排查某些框架类找不到的问题时首先要想的不是依赖有没有引而是当前线程的 TCCL 被谁改了。5. 打破双亲委派的实战场景SPI、容器隔离与热部署双亲委派不是银弹在某些场景下必须主动打破它。这一节我会讲三个非常典型的场景JDBC 驱动的 SPI 加载、Tomcat 的类隔离以及用自定义 ClassLoader 实现热部署。5.1 SPI 机制为什么默认的双亲委派加载不到 JDBC 驱动上文提到了DriverManager的例子这里展开讲一下 SPI 的完整逻辑。SPI 全称 Service Provider Interface是 Java 内置的服务发现机制。JDK 在META-INF/services目录下放了一个配置文件里面写了接口的标准实现类运行时由框架动态加载。DriverManager的初始化代码里有一个loadInitialDrivers()方法它做的事就是读取META-INF/services/java.sql.Driver文件拿到驱动的全限定名然后调用Class.forName(driverName, true, classLoader)加载。注意这里的classLoader参数取的就是Thread.currentThread().getContextClassLoader()。所以 Spring Boot 应用里连接 MySQL 能正常工作本质上是线程上下文类加载器帮了忙。如果你想在纯 Java SE 环境里手写一个 SPI 加载器记住一个原则当你发现某个实现类在 classpath 里却加载不到时优先检查上下文类加载器是否被换掉了。这是我在实际排查中踩过最多次的坑。5.2 Tomcat 为什么要打破双亲委派Tomcat 的类加载器体系是打破双亲委派最典型的例子。为什么它要这么做因为 Tomcat 要解决两个问题。第一个是隔离问题。一个 Tomcat 容器里可能部署多个 Web 应用每个应用有自己的依赖 jar 包。如果都遵循双亲委派应用 A 和应用 B 依赖同一个 jar 包的同一个类会被同一个应用类加载器加载互相污染版本冲突时根本没法处理。Tomcat 的解决方案是为每个 Web 应用创建独立的 WebAppClassLoader应用类的加载请求优先由 WebAppClassLoader 自己处理实在找不到才委派给父加载器。第二个是热部署问题。修改 JSP 或 class 文件后Tomcat 需要在不重启的情况下重新加载应用。如果所有类都用同一个加载器加载类无法被卸载更新根本无从谈起。Tomcat 的做法是检测到文件变化后直接丢弃旧的 WebAppClassLoader创建一个新的用新加载器重新加载所有类。老的类由于没有引用可以正常被回收。建议你平时在 IDEA 里启动一次 Tomcat观察日志里输出的一长串类似于TomcatWebAppClassLoader的信息再对照 Tomcat 官方文档里的类加载器结构图会有非常直观的感受。5.3 手写一个自定义 ClassLoader 实现热部署关于 ClassLoader 的实战热部署是最能练手的方向。原理不复杂既然同一个 ClassLoader 对同名类的加载结果只有一次那我想更新类就只能换一个新 ClassLoader 重新加载。新加载器不走缓存自然能拿到最新的字节码。一个最小可用的热部署 Demo核心就三步。第一步继承ClassLoader重写findClass()方法在方法里读取指定路径的.class字节码调用defineClass()生成 Class 对象。第二步用一个定时任务扫描 class 文件的变化发现修改时间变了就创建新的类加载器。第三步通过反射调用新加载器加载出来的类的方法。public class HotSwapClassLoader extends ClassLoader { private String classPath; public HotSwapClassLoader(String classPath) { this.classPath classPath; } Override protected Class? findClass(String name) throws ClassNotFoundException { String fileName classPath / name.replace(., /) .class; byte[] bytes readBytes(fileName); return defineClass(name, bytes, 0, bytes.length); } private byte[] readBytes(String file) { // 省略读取文件内容为字节数组 } }注意两个容易翻车的点。第一字节码修改后如果类的结构变了比如加了字段、改了方法签名用反射调用的代码也要对应调整否则会抛NoSuchMethodException。第二被替换的旧类仍然可能被常量池里的旧引用持有导致内存回收不掉长时间运行后容易造成方法区内存泄漏。所以在生产环境做热更新建议不要手动造轮子直接上 JRebel、Arthas 这类成熟工具思路参考官方实现就好。6. 面试与实战高频问题排雷手册最后一部分我把类加载机制这块最容易栽跟头的面试题和线上问题整理成一个速查手册每一条都结合我自己的排查经验来讲。6.1 ClassNotFoundException 和 NoClassDefFoundError 怎么分清这是我被问过无数次也看别人在群里问过无数次的一个问题。这两个错误名字很像但本质完全不同。ClassNotFoundException是一个受检异常抛出的场景是非常明确的你调用Class.forName()、ClassLoader.loadClass()、ClassLoader.findSystemClass()等方法显式要求类加载器去加载某个类但加载器在 classpath 里找不到对应的类定义。排查思路很简单先确认全限定名是不是写错了再确认对应的 jar 包有没有被正确引入、是否在预期范围内被不同加载器加载。NoClassDefFoundError是一个Error不是异常。它的触发场景是类在编译期是存在的但运行时引用的类在类加载阶段出了问题。最常见的两种情况一是这个类在编译后被打包时缺失了比如构建工具没把这个类所在模块打进去二是这个类的初始化失败了静态初始化器里抛了异常JVM 在后续使用时会直接抛NoClassDefFoundError而不是重新尝试初始化。我在排查线上问题时通常会先把错误打印的堆栈完整看一遍特别是第一行到底是 Exception 还是 Error。如果看到NoClassDefFoundError我第一反应不是去看依赖而是去查这个类所在的初始化逻辑是不是有问题。有一次某个同事的线上服务频繁报NoClassDefFoundError查到最后就是一个工具类的静态代码块里连接配置中心超时导致类初始化失败。简单说一个约等于“类不在 classpath”一个约等于“类在但加载失败了”方向完全不同。6.2 双亲委派相关的典型面试题与答题思路面试时围绕这个知识点翻来覆去就那几道题但答到深度的人不多。第一道双亲委派模型是什么为什么需要它。答的时候先讲流程再讲原因重点放在避免重复加载和保证核心库安全上加一句“这是 Java 核心 API 不被恶意篡改的关键设计”。第二道如何打破双亲委派模型。答题时列举三种方式重写loadClass()方法使用线程上下文类加载器绕过父加载器限制利用 SPI 机制。上面都讲到了但注意答的时候要提到“打破并不代表所有场景都适合需要配合类隔离的需求慎重使用”。第三道判断两个类是否相等条件是什么。这是一个很容易漏答案的问题除了类的全限定名相同之外还要类加载器相同。类加载器不同即使从同一个 class 文件加载出来的 Class 对象也不相等instanceof返回 false。这条要是能在答题时加上一个“比如 Tomcat 里多个 WebAppClassLoader 加载同一个类的情况”基本就稳了。第四道SPI 与双亲委派冲突框架是怎么处理的。核心答线程上下文类加载器要能说清楚父加载器加载的代码如何借助子加载器去加载实现类。这些题不需要死记硬背把源码逻辑和设计初衷理解了稍微组织一下语言就能答得很好。6.3 线上排查工具与日常排查建议除了面试类加载机制在平时排查问题时的角色也很重要。我实操中用的比较多的工具有这些jps jstack查看 Java 进程和线程栈看到类初始化死锁这类问题时很有用。jcmd或jmap -clstats查看类加载器的统计信息能看到每个加载器加载了多少个类。-verbose:class启动参数打印类加载和卸载的日志输出格式里会明确标注类是哪个加载器加载的排查类归属问题时简直利器。-Xlog:classloadinfoJDK 9 之后的新版日志开关格式更清晰。Arthas 的classloader命令、sc命令线上也能精准定位类的加载关系和来源。做了一个简单对照表方便以后翻工具/参数作用适用场景-verbose:class打印类加载/卸载日志启动期定位类加载顺序jmap -clstats查看各加载器的类数量排查类加载器数量异常Arthas classloader查看类加载器层级和加载的 class线上定位类被谁加载Arthas sc查看类的详细信息确认类来源与加载器最后分享一个我自己的排查习惯遇到类相关的问题不要急着加日志或改代码先确认“这个类到底该由谁加载、当前被谁加载了”。用-verbose:class起一次服务或者用 Arthas 查一下绝大多数问题在看清加载关系的那一刻就已经有答案了。类加载机制这块内容我每年都要重新翻一遍因为 JDK 迭代后细节会变比如 JDK 9 模块化对加载路径的调整但双亲委派的设计思想和排查思路是非常稳定的。把它彻底吃透你不仅面试时能多拿分线上遇到诡异问题时心里也会更有底。
