前些天被拉去帮忙排查一个线上启动问题日志里反复出现ClassNotFoundException第一反应是把依赖树从头查一遍。jar 包在、字节码也能解压出来、类文件确实躺在那儿可应用就是起不来。折腾到最后才发现问题压根不在依赖而在类加载机制本身——没有这个类和当前类加载器看不到这个类是两回事。也就是这次排查让我决定把 JVM 类加载机制从头到尾整理一遍内容包括类加载的五个阶段、类加载器体系和双亲委派模型、以及排查类加载问题时真正用得上的经验。这个话题不新鲜但每次用到都能救场值得静下心把细节抠明白。1. 类加载全流程拆解从字节码到可运行类很多人一提类加载张口就是加载、验证、准备、解析、初始化这五个词但每个阶段到底做了什么、在哪一步会出什么问题能说清楚的不多。这一章按阶段拆开讲每一步都落到可观测的行为上。1.1 加载阶段从二进制流到内存中的 Class 对象加载阶段要做三件事通过类的全限定名获取二进制字节流把字节流中的静态存储结构转换为方法区的运行时数据结构在堆中生成一个代表这个类的 Class 对象作为方法区这个类各种数据的访问入口。这个阶段有三个细节值得单独拎出来说。第一字节流的来源没有限制。我们日常开发的类是从 classpath 下的 .class 文件读出来的但规范只要求通过全限定名获取二进制字节流至于字节流来自文件系统、网络、数据库、内存中动态生成都可以。自定义类加载器之所以能做热部署、字节码增强基础就落在这里。第二同一个二进制字节流被不同的类加载器加载在 JVM 眼里是两个完全不同的类。所以类的唯一标识是全限定名 定义它的加载器而不是单纯的类名。这个结论是很多诡异异常的根源后面排查章节会反复用到。第三加载阶段完成时类还没有真正进入可用状态。此时 Class 对象已经存在了但类的字段、方法还没经过校验执行引擎随时可能因为一份畸形字节码而出问题所以紧随其后的验证阶段绝不能跳过。1.2 验证阶段加载前的安全防线验证阶段经常被人忽略但它是最容易被低估的一环。JVM 需要保证字节流中的字节码不会危害虚拟机自身的安全。不要觉得我 javac 编译出来的还能有什么问题要知道字节流不一定来自编译器的产物它可能来自网络传输、动态代理生成的字节码、字节码修改工具二次加工过的类。验证阶段大体包含四类检查文件格式验证魔数是否为 0xCAFEBABE、主次版本号是否受当前 JVM 支持、常量池中是否有不支持的常量类型。元数据验证父类是否存在、是否继承了 final 类、是否实现了所有抽象方法、字段和方法是否有与父类冲突的定义。字节码验证这是最复杂的一环通过数据流分析判断操作数栈的深度、局部变量表的使用是否合法不允许跳转指令跳到非法位置。符号引用验证常量池中的符号引用能否找到对应的直接引用比如通过字符串描述的全限定名能不能找到对应的类。实际开发中同一个包里有某个类是用高版本 JDK 编译的放到低版本 JDK 上跑很多时候就挂在文件格式验证或者字节码验证上。如果排查时想快速确认是不是验证阶段出的问题可以临时加-Xverify:none跳过验证看启动是否恢复正常。注意生产环境不要长期关验证这只是缩小排查范围的手段。1.3 准备阶段静态变量从零值开始准备阶段是正式为类中的静态变量分配内存并设置默认值的阶段。这里有两个字要划重点分配和默认值。分配说的是只给类变量分配内存不包含实例变量。这些内存在方法区或者元空间里统一管理。默认值说的是这个阶段设置的初值是 JVM 的零值不是代码里写的赋值。比如private static int a 100;准备阶段结束时 a 的值是 0真正赋 100 要等到初始化阶段的clinit方法执行。但private static final int CONSTANT 100;又不一样编译期能确定的常量准备阶段就直接在常量池里拿到了正确值。代码写法准备阶段的值说明static int a 100;0非 final编译期不传播初始化时才赋值static final int b 100;100编译期常量准备阶段即定值static Object obj new Object();null引用类型的零值是 nullstatic boolean flag true;falseboolean 的零值是 false这个细节平时看起来人畜无害但排查动态生成的字节码时很有用。有些框架会在运行时改字段的赋值时机同一份类在不同阶段加载静态字段呈现出的值会不一样根源往往就在准备阶段和初始化阶段的职责划分上。1.4 解析阶段符号引用替换为直接引用解析阶段是把常量池里的符号引用替换为直接引用的过程。符号引用是一组描述目标叫什么、长什么样的常量比如类和接口的全限定名、字段名及描述符、方法名及描述符。直接引用则是能直接定位到目标内存地址的引用类的直接引用可以指向方法区里的类数据字段的直接引用可以是字段在实例中的偏移量。最常见的误区是认为所有解析都发生在初始化之前。其实 JVM 允许在符号引用被真实使用到的时候才去解析这称为延迟解析。第一次遇到相关指令时解析后续再遇到同样引用时直接复用解析结果。好处很明显不需要在启动时把所有常量池都翻一遍能省不少启动时间。需要解析的引用类型包括类与接口、字段、方法、接口方法、方法类型、方法句柄、调用点限定符。其中类和接口的解析是最容易出问题的解析一个类的父类和接口时需要递归处理一旦某个父类无法加载直接抛NoClassDefFoundError。1.5 初始化阶段真正开始执行用户代码初始化阶段是类加载的临门一脚执行的是clinit()方法。这个方法由编译器自动收集类中所有静态变量的赋值动作和静态代码块中的语句合并生成顺序与源码中出现的顺序一致。静态块中可以给后面声明的变量赋值但不能在声明之前读取它否则编译器会报非法的前向引用。clinit执行有一个极其重要的特性线程安全。多个线程同时触发同一个类的初始化时JVM 会保证只有一个线程执行clinit其他线程进入阻塞等待。如果你在静态块里写了耗时操作甚至死循环线上会出现大量线程莫名 block 的现象jstack一抓能看到成片线程卡在clinit帧上。父类的初始化一定先于子类。JVM 会保证初始化子类之前父类已经初始化完成。接口则没有这个强制要求父接口只有在真正被使用时才需要初始化。还有一点是关于主动引用和被动引用的区分。所谓主动引用是指代码确有立刻初始化该类的语义比如 new 对象、读写静态字段非常量、调用静态方法、使用反射、初始化子类时连带初始化父类、JVM 启动时初始化包含 main 方法的类等。被动引用则是那些看起来碰了这个类、但本不需要初始化它的情况典型的三个例子通过子类访问父类的静态字段子类不会被初始化。通过数组定义来引用类Parent[] arr new Parent[10];不会触发 Parent 的初始化。引用编译期常量比如Constants.MAX编译后常量值直接写入了调用方Constants 根本不需要加载。判断是否真的需要初始化这个思路特别重要。你写了一个类在静态块里做全局资源预热结果发现预热代码根本没执行回头查一下是不是这些触发路径都落在了被动引用的范畴里往往一找一个准。2. 类加载器体系与双亲委派模型类加载器是类加载动作的发起者也是整个机制里最体现设计思想的部分。理解类加载器体系就理解了为什么有些类明明在 classpath 里运行时却看不到。2.1 三种内置类加载器的分工JVM 提供三层内置于 JDK 的类加载器启动类加载器Bootstrap ClassLoader负责加载 JDK 核心类库。这个加载器没有父加载器也不是 Java 代码能直接拿到的对象如果你打印一个核心类的getClassLoader()结果是 null。扩展类加载器Extension ClassLoader负责加载 JDK 扩展目录下的 jar 包。JDK 模块化之后它的职责被平台类加载器继承负责加载一些平台模块和扩展模块。应用类加载器Application ClassLoader负责加载 classpath 下的所有类。我们在 IDE 里跑的大多数业务类都由它加载因此也叫系统类加载器。在实战视角下可以把这三层简单理解为核心 Java 库、JDK 平台模块、业务代码的边界。大部分问题都出在业务代码这一层和应用服务器自己创建的类加载器之间的交互上。2.2 双亲委派把加载请求先交给父加载器双亲委派模型的工作规则非常朴素当一个类加载器收到类加载请求它不会自己直接加载而是先把请求委托给父加载器。父加载器也按同样的逻辑继续上抛直到启动类加载器。只有父加载器反馈无法完成加载时子加载器才会尝试自己加载。这么设计的好处很直观。以java.lang.String为例不管哪个类加载器收到加载请求最终都会委托给启动类加载器从核心库拿到同一份类定义。这就保证了 Java 核心类在任意环境中都是同一份也防止用户自己写一个同名类覆盖掉系统核心 API破坏运行稳定。如果你想实践双亲委派自定义类加载器时最标准的做法是重写findClass而不是loadClass。loadClass是模板方法委派逻辑已经写死在里面findClass是留给子类的扩展点负责真正找到并生成字节流和 Class 对象。public class HotClassLoader extends ClassLoader { Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] bytes readClassFileBytes(name); if (bytes null) { throw new ClassNotFoundException(name); } return defineClass(name, bytes, 0, bytes.length); } private byte[] readClassFileBytes(String name) { String path name.replace(., /).concat(.class); try (InputStream in getClass().getClassLoader().getResourceAsStream(path)) { if (in null) { return null; } return in.readAllBytes(); } catch (IOException e) { return null; } } }这段代码里没有动loadClass所以双亲委派链路依然完整。真要打破委派就得重写loadClass那就得想清楚后续类的命名空间怎么管了。2.3 双亲委派为什么需要被打破双亲委派不是万能的典型反例是 JDBC 驱动的加载。DriverManager本身由启动类加载器加载它需要通过 ServiceLoader 机制去加载驱动实现但驱动实现类却在业务 classpath 下。如果严格按双亲委派启动类加载器永远不会往下找驱动永远加载不到。解决思路就是引入线程上下文类加载器把加载请求转交给应用类加载器去处理。另一个反例是 Web 容器和应用隔离。一个容器需要管理多个应用每个应用可能有不同版本的第三方依赖如果全部交给同一个应用类加载器版本冲突会非常严重。容器通常会给每个应用创建独立的类加载器这些类加载器的父加载器指向一个公共容器加载器从而让不同应用之间的类相互隔离。打破双亲委派的关键不是技术上能不能做而是做完之后类的命名空间怎么管理。当你引入一个新的类加载器实例去加载某个类文件时这个类相对于默认加载器加载的同名类就成了两个类强转、instanceof、反射调用都会受影响。所以线上做类隔离时一定要把公共依赖提升到父加载器去加载只隔离真正需要隔离的部分。2.4 线程上下文类加载器到底是干什么的线程上下文类加载器也就是 TCCL存在在 Thread 类中默认继承创建线程时的上下文加载器。它的核心价值是给由父加载器加载的代码提供一个反向使用子加载器的入口。最典型的是各种 SPI 机制。核心接口由启动类加载器加载实现类却由应用类加载器加载。当核心代码需要加载具体实现时它不知道该用哪个加载器于是借助当前线程的 TCCL 去加载把类加载请求交还给业务侧。ServiceLoader的实现就依赖这个机制。平时写业务代码使用 TCCL 的频率确实不高但排查框架初始化问题时非常有用。比如某个扩展点加载不到实现类可以先检查当前线程的 TCCL 是不是被框架改过改成了哪个类加载器再看这个加载器能否覆盖到实现类所在的位置。多问一句当前线程的上下文加载器是谁很多诡异现象就能串起来了。3. 类加载过程中的边界细节与高频易错点这一章专门讲细节。类加载机制的难点不在于五阶段背不背得下来而在于各种边界情况下的行为是否符合直觉。3.1 数组类的加载规则数组类和普通类的加载路径差异很大。数组类本身并不通过类加载器创建而是由 JVM 在运行时直接构造。如果数组的元素是引用类型JVM 会先去加载元素类型然后再创建数组类本身。数组类的类加载器与元素类型的类加载器保持一致如果是基本类型的数组类加载器被认为是 null启动类加载器。这就解释了一个现象String[].class.getClassLoader()返回 null而自定义业务类的数组getClassLoader()返回的是应用类加载器。很多人第一次看到这个结果会愣一下以为数组类都是 null实际上规则很明显——看元素类型归属于谁。这个细节还带来一个衍生结论数组类的创建不触发元素类的初始化。Parent[] arr new Parent[10]只创建数组类Parent 本体依然不会被初始化。这也是被动引用里最经典的例子之一。3.2 主动引用与被动引用的准确边界主动引用和被动引用的边界是面试和实战都爱考的细节。前面已经列过主动引用的常见场景这里重点说被动引用的三个容易误判的例子。第一个通过子类引用父类静态字段。比如Child.xx 定义在 Parent 里编译后字节码访问的仍然是 Parent 的字段所以只有 Parent 会被初始化Child 不会。注意不要和初始化子类时父类会先初始化混淆那条规则说的是子类真正需要被初始化时父类抢先而这里 Child 压根不需要初始化。第二个定义数组。刚才已经解释过数组类不触发元素类的初始化。第三个编译期常量传播。public static final int MAX 10;这种常量在编译期就把值写进了调用方的常量池运行期调用方根本不会引用到 Constants 类。很多瘦身优化能删掉大量类就是建立在常量传播的基础上。理解这三条的价值在于当你期望某个类在启动时执行静态初始化做点事情但要确保触发路径是真正的主动引用比如直接读写一个非常量静态字段或者显式调用Class.forName。3.3 类的卸载与 Class 对象的生命周期类的卸载不是单独发生的它和类加载器的生命周期绑定。如果一个自定义类加载器没有任何强引用指向它那么它加载的所有类都进入可回收状态。反过来只要类加载器还被某个对象持有引用它加载过的所有类都不会被卸载。这对排查元空间 OOM 特别重要。如果代码里反复创建自定义类加载器去加载类但加载器对象被某个集合或框架缓存住了内存就会越涨越高。常见的解决办法是检查是谁持有了这些加载器引用把缓存清理掉让加载器连同它加载的类一起被回收。另一个和卸载相关的场景是热部署。热部署之所以能生效说到底就是旧类加载器 旧类一起被废弃新加载器 新类重新建立。只替换 class 文件而不替换加载器是达不到预期的。3.4clinit的执行顺序与潜在的初始化死锁clinit的执行顺序前文提过父类先于子类静态字段赋值和静态代码块按源码顺序执行。这里再提一个比较极端的坑类初始化死锁。假设线程 A 触发类 X 的初始化X 的静态代码块依赖类 Y 的初始化同时线程 B 触发类 Y 的初始化Y 的静态代码块依赖类 X 的初始化。由于 JVM 保证每个类的clinit只能由一个线程执行另一个线程会等待这两个线程就可能互相等成死锁。这类问题比较罕见但真出现时很吓人因为jstack里能看到成片线程 block 在类初始化帧上业务代码完全没动静。定位思路是先看有没有多个类在静态初始化期互相调用重构掉静态块中的复杂逻辑把初始化动作拆到更可控的位置。4. 类加载问题排查实录从报错到定位的完整路径大量的类加载问题都有相似的外壳真正要命的是外壳下面的真实原因。这一章整理几个高频问题的定位方法和思路。4.1 ClassNotFoundException 和 NoClassDefFoundError 的准确区分这两个名字长得像发生机制却完全不同。ClassNotFoundException是受检异常发生在主动去加载类却找不到的时候比如Class.forName、ClassLoader.loadClass、findSystemClass这些调用路径。它通常意味着类真的不在当前加载器可覆盖的范围内。NoClassDefFoundError是 Error发生时机更隐蔽类在编译期存在本应加载成功但某个指令运行到一半时再查询类却失败了。一个特别典型的场景是某个类B的静态初始化抛出异常JVM 把它标记为加载失败之后所有需要用到B的代码都不再尝试加载它直接抛NoClassDefFoundError。所以排查时如果看到NoClassDefFoundError不要只盯着当前这一条报错往前翻日志找出它第一次加载失败时抛出的异常那才是真正的根因。很多新人被这个表象误导反复重启浪费大量时间。4.2 同名类不同加载器引发的 ClassCastException类由全限定名 定义加载器唯一确定。这意味着同名的类只要加载器不同在 JVM 中就是两个类型。实际表现是两个对象从内容上看完全一致接口也一致但instanceof返回 false强转直接抛ClassCastException。我排查过一个非常有代表性的案例同一个服务里内嵌了两套框架各自创建了独立类加载器加载了一个公共库的不同版本。公共库里的接口在两个加载器里各有一份实现代码互相调用时强转失败。定位思路是先打印两边的类加载器确认归属再把公共依赖上移到同一个父加载器让两套框架共享相同定义。排查时有一个通用步骤调用object.getClass().getClassLoader()和targetClass.getClassLoader()对比这两个加载器是不是同一个实例。如果不同就需要从依赖治理角度解决而不是写代码绕过。4.3 如何快速定位类是从哪里加载的定位类加载来源最直接的方法是启动时加-verbose:class。它会打印出每个类的加载来源能看到类是从哪个 jar 或者文件路径加载进来的也能看到同一个类被重复加载的情况。新版 JDK 可以用-Xlog:classloadinfo输出格式更友好。如果服务已经跑起来了可以找当前进程用 JDK 自带工具连接上去查询指定类的加载器。实际使用中我更喜欢先通过日志输出确认类加载器类型再打印它的URLClassLoader的 URL 列表这样能直接看到它扫描了哪些路径。跨框架、跨类加载器的问题靠这个方式能很快确认类到底在哪一层。排查依赖冲突时还有个反向思路把可疑的 jar 逐个用jar命令解压检查类文件是否真的存在再对比 classpath 的加载顺序。但这是低效的更好的做法是借助依赖树工具把传递依赖捋清楚看谁把旧版本带进来了。4.4 一个最简热加载实现理解原理但不能照搬生产热部署的原理就是自定义类加载器加定时检测类文件的修改时间。每次检测到变更创建新的类加载器加载新的 byte[]新旧类因为所属加载器不同互不影响。前面那段 HotClassLoader 代码就是最简原型。public class HotDeployer { public static Object loadNewInstance(String className) throws Exception { HotClassLoader loader new HotClassLoader(); Class? clazz loader.loadClass(className); return clazz.getDeclaredConstructor().newInstance(); } }每调用一次loadNewInstance都会用一个新的加载器去加载类得到的是新版本。但生产环境要做的事情远比这个多旧对象引用的清理、容器线程的释放、加载器实例的缓存管理、序列化 id 的变化每一项都能单独写一篇。我个人的建议是生产环境用成熟的热部署方案本文这一段只用于理解原理和排查问题千万不要自己造轮子直接上生产。4.5 Class.forName 和 ClassLoader.loadClass 的行为差异Class.forName(com.xxx.A)默认会触发类的初始化也就是会执行静态块和静态字段赋值。ClassLoader.loadClass(com.xxx.A)默认不触发初始化只完成加载。很多数据库驱动在注册时需要执行静态初始化所以用 Class.forName 加载就是对的如果只做类信息的预载用 loadClass 就够了还能避免不必要的静态逻辑执行。这个差异一旦搞混线上会出现同一段代码在某个版本正常、换个版本就异常的情况。其实不是框架坏了而是类初始化的触发时机变了。5. 面试追问清单与避坑指南最后一部分给准备面试和希望系统复习的朋友一份速查清单。5.1 高频追问与答题思路围绕类加载机制的面试提问基本有几条主线双亲委派模型为什么这么设计核心类安全、避免同名类重复加载、保证一致性和安全性。双亲委派能被破坏吗哪些场景会破坏SPI、Web 容器、热部署、OSGi 式模块化都是典型场景。五个阶段各自做了什么其中哪些阶段会抛出可预期的异常Class.forName和ClassLoader.loadClass的区别是什么同一个类文件由两个类加载器加载为什么不是同一个类数组类的类加载器怎么算它会被初始化吗这些问题答得清楚说明你已经把类加载机制从背概念提升到了理解行为的层面。5.2 经典输出题初始化顺序静态初始化、实例初始化、构造函数、继承关系叠加在一起是面试里最常出的输出题。class Parent { static { System.out.println(Parent static); } { System.out.println(Parent block); } public Parent() { System.out.println(Parent cons); } } class Child extends Parent { static { System.out.println(Child static); } { System.out.println(Child block); } public Child() { System.out.println(Child cons); } }执行new Child()输出结果是Parent static Child static Parent block Parent cons Child block Child cons原因拆开看就一句话静态初始化只在类首次加载时发生且父类先于子类实例初始化阶段父类的构造器先运行然后才轮到子类的实例初始化和构造器。这个顺序掌握好大多数变体题都能稳。5.3 实战避坑清单不要随便重写loadClass。实现自定义加载器时优先重写findClass让默认委派逻辑保留。不要默认Class.forName和ClassLoader.loadClass等价。走forName前确认是否真的需要触发静态初始化。注意接口初始化的规则和抽象类不同不要拿类的逻辑硬套接口。关注自定义加载器对象的持有方避免因为加载器不可回收导致元空间持续上涨。热部署上线前一定要验证旧对象和新类的兼容性否则会埋伏下强转失败和反射混乱的风险。看到NoClassDefFoundError时先往前翻日志找到它真实的初始化失败原因而不是盯着最后一条报错反复重启。最后说点个人体会。类加载机制掌握到什么程度决定了你能把 JVM 问题排查到哪一层。很多人处理线上异常只愿意看业务日志可一旦报错来自类加载这几个字如果没有对整个链路形成画面感就很容易把问题甩给环境不对或者依赖冲突然后陷入反复重启的循环。真正把五个阶段、三个加载器、双亲委派模型串成一条线之后你会发现自己看日志的敏感度都不一样了——会主动去想这个异常是验证没过、准备阶段分配内存没对、解析阶段找不到父类、还是clinit根本没执行成功。很多时候多问自己一句它应该被哪个类加载器加载问题答案就自己浮出来了。希望这篇整理能帮你建立自己的排查感觉下次碰到类加载相关的报错不再靠重启解决。
前些天被拉去帮忙排查一个线上启动问题日志里反复出现ClassNotFoundException第一反应是把依赖树从头查一遍。jar 包在、字节码也能解压出来、类文件确实躺在那儿可应用就是起不来。折腾到最后才发现问题压根不在依赖而在类加载机制本身——没有这个类和当前类加载器看不到这个类是两回事。也就是这次排查让我决定把 JVM 类加载机制从头到尾整理一遍内容包括类加载的五个阶段、类加载器体系和双亲委派模型、以及排查类加载问题时真正用得上的经验。这个话题不新鲜但每次用到都能救场值得静下心把细节抠明白。1. 类加载全流程拆解从字节码到可运行类很多人一提类加载张口就是加载、验证、准备、解析、初始化这五个词但每个阶段到底做了什么、在哪一步会出什么问题能说清楚的不多。这一章按阶段拆开讲每一步都落到可观测的行为上。1.1 加载阶段从二进制流到内存中的 Class 对象加载阶段要做三件事通过类的全限定名获取二进制字节流把字节流中的静态存储结构转换为方法区的运行时数据结构在堆中生成一个代表这个类的 Class 对象作为方法区这个类各种数据的访问入口。这个阶段有三个细节值得单独拎出来说。第一字节流的来源没有限制。我们日常开发的类是从 classpath 下的 .class 文件读出来的但规范只要求通过全限定名获取二进制字节流至于字节流来自文件系统、网络、数据库、内存中动态生成都可以。自定义类加载器之所以能做热部署、字节码增强基础就落在这里。第二同一个二进制字节流被不同的类加载器加载在 JVM 眼里是两个完全不同的类。所以类的唯一标识是全限定名 定义它的加载器而不是单纯的类名。这个结论是很多诡异异常的根源后面排查章节会反复用到。第三加载阶段完成时类还没有真正进入可用状态。此时 Class 对象已经存在了但类的字段、方法还没经过校验执行引擎随时可能因为一份畸形字节码而出问题所以紧随其后的验证阶段绝不能跳过。1.2 验证阶段加载前的安全防线验证阶段经常被人忽略但它是最容易被低估的一环。JVM 需要保证字节流中的字节码不会危害虚拟机自身的安全。不要觉得我 javac 编译出来的还能有什么问题要知道字节流不一定来自编译器的产物它可能来自网络传输、动态代理生成的字节码、字节码修改工具二次加工过的类。验证阶段大体包含四类检查文件格式验证魔数是否为 0xCAFEBABE、主次版本号是否受当前 JVM 支持、常量池中是否有不支持的常量类型。元数据验证父类是否存在、是否继承了 final 类、是否实现了所有抽象方法、字段和方法是否有与父类冲突的定义。字节码验证这是最复杂的一环通过数据流分析判断操作数栈的深度、局部变量表的使用是否合法不允许跳转指令跳到非法位置。符号引用验证常量池中的符号引用能否找到对应的直接引用比如通过字符串描述的全限定名能不能找到对应的类。实际开发中同一个包里有某个类是用高版本 JDK 编译的放到低版本 JDK 上跑很多时候就挂在文件格式验证或者字节码验证上。如果排查时想快速确认是不是验证阶段出的问题可以临时加-Xverify:none跳过验证看启动是否恢复正常。注意生产环境不要长期关验证这只是缩小排查范围的手段。1.3 准备阶段静态变量从零值开始准备阶段是正式为类中的静态变量分配内存并设置默认值的阶段。这里有两个字要划重点分配和默认值。分配说的是只给类变量分配内存不包含实例变量。这些内存在方法区或者元空间里统一管理。默认值说的是这个阶段设置的初值是 JVM 的零值不是代码里写的赋值。比如private static int a 100;准备阶段结束时 a 的值是 0真正赋 100 要等到初始化阶段的clinit方法执行。但private static final int CONSTANT 100;又不一样编译期能确定的常量准备阶段就直接在常量池里拿到了正确值。代码写法准备阶段的值说明static int a 100;0非 final编译期不传播初始化时才赋值static final int b 100;100编译期常量准备阶段即定值static Object obj new Object();null引用类型的零值是 nullstatic boolean flag true;falseboolean 的零值是 false这个细节平时看起来人畜无害但排查动态生成的字节码时很有用。有些框架会在运行时改字段的赋值时机同一份类在不同阶段加载静态字段呈现出的值会不一样根源往往就在准备阶段和初始化阶段的职责划分上。1.4 解析阶段符号引用替换为直接引用解析阶段是把常量池里的符号引用替换为直接引用的过程。符号引用是一组描述目标叫什么、长什么样的常量比如类和接口的全限定名、字段名及描述符、方法名及描述符。直接引用则是能直接定位到目标内存地址的引用类的直接引用可以指向方法区里的类数据字段的直接引用可以是字段在实例中的偏移量。最常见的误区是认为所有解析都发生在初始化之前。其实 JVM 允许在符号引用被真实使用到的时候才去解析这称为延迟解析。第一次遇到相关指令时解析后续再遇到同样引用时直接复用解析结果。好处很明显不需要在启动时把所有常量池都翻一遍能省不少启动时间。需要解析的引用类型包括类与接口、字段、方法、接口方法、方法类型、方法句柄、调用点限定符。其中类和接口的解析是最容易出问题的解析一个类的父类和接口时需要递归处理一旦某个父类无法加载直接抛NoClassDefFoundError。1.5 初始化阶段真正开始执行用户代码初始化阶段是类加载的临门一脚执行的是clinit()方法。这个方法由编译器自动收集类中所有静态变量的赋值动作和静态代码块中的语句合并生成顺序与源码中出现的顺序一致。静态块中可以给后面声明的变量赋值但不能在声明之前读取它否则编译器会报非法的前向引用。clinit执行有一个极其重要的特性线程安全。多个线程同时触发同一个类的初始化时JVM 会保证只有一个线程执行clinit其他线程进入阻塞等待。如果你在静态块里写了耗时操作甚至死循环线上会出现大量线程莫名 block 的现象jstack一抓能看到成片线程卡在clinit帧上。父类的初始化一定先于子类。JVM 会保证初始化子类之前父类已经初始化完成。接口则没有这个强制要求父接口只有在真正被使用时才需要初始化。还有一点是关于主动引用和被动引用的区分。所谓主动引用是指代码确有立刻初始化该类的语义比如 new 对象、读写静态字段非常量、调用静态方法、使用反射、初始化子类时连带初始化父类、JVM 启动时初始化包含 main 方法的类等。被动引用则是那些看起来碰了这个类、但本不需要初始化它的情况典型的三个例子通过子类访问父类的静态字段子类不会被初始化。通过数组定义来引用类Parent[] arr new Parent[10];不会触发 Parent 的初始化。引用编译期常量比如Constants.MAX编译后常量值直接写入了调用方Constants 根本不需要加载。判断是否真的需要初始化这个思路特别重要。你写了一个类在静态块里做全局资源预热结果发现预热代码根本没执行回头查一下是不是这些触发路径都落在了被动引用的范畴里往往一找一个准。2. 类加载器体系与双亲委派模型类加载器是类加载动作的发起者也是整个机制里最体现设计思想的部分。理解类加载器体系就理解了为什么有些类明明在 classpath 里运行时却看不到。2.1 三种内置类加载器的分工JVM 提供三层内置于 JDK 的类加载器启动类加载器Bootstrap ClassLoader负责加载 JDK 核心类库。这个加载器没有父加载器也不是 Java 代码能直接拿到的对象如果你打印一个核心类的getClassLoader()结果是 null。扩展类加载器Extension ClassLoader负责加载 JDK 扩展目录下的 jar 包。JDK 模块化之后它的职责被平台类加载器继承负责加载一些平台模块和扩展模块。应用类加载器Application ClassLoader负责加载 classpath 下的所有类。我们在 IDE 里跑的大多数业务类都由它加载因此也叫系统类加载器。在实战视角下可以把这三层简单理解为核心 Java 库、JDK 平台模块、业务代码的边界。大部分问题都出在业务代码这一层和应用服务器自己创建的类加载器之间的交互上。2.2 双亲委派把加载请求先交给父加载器双亲委派模型的工作规则非常朴素当一个类加载器收到类加载请求它不会自己直接加载而是先把请求委托给父加载器。父加载器也按同样的逻辑继续上抛直到启动类加载器。只有父加载器反馈无法完成加载时子加载器才会尝试自己加载。这么设计的好处很直观。以java.lang.String为例不管哪个类加载器收到加载请求最终都会委托给启动类加载器从核心库拿到同一份类定义。这就保证了 Java 核心类在任意环境中都是同一份也防止用户自己写一个同名类覆盖掉系统核心 API破坏运行稳定。如果你想实践双亲委派自定义类加载器时最标准的做法是重写findClass而不是loadClass。loadClass是模板方法委派逻辑已经写死在里面findClass是留给子类的扩展点负责真正找到并生成字节流和 Class 对象。public class HotClassLoader extends ClassLoader { Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] bytes readClassFileBytes(name); if (bytes null) { throw new ClassNotFoundException(name); } return defineClass(name, bytes, 0, bytes.length); } private byte[] readClassFileBytes(String name) { String path name.replace(., /).concat(.class); try (InputStream in getClass().getClassLoader().getResourceAsStream(path)) { if (in null) { return null; } return in.readAllBytes(); } catch (IOException e) { return null; } } }这段代码里没有动loadClass所以双亲委派链路依然完整。真要打破委派就得重写loadClass那就得想清楚后续类的命名空间怎么管了。2.3 双亲委派为什么需要被打破双亲委派不是万能的典型反例是 JDBC 驱动的加载。DriverManager本身由启动类加载器加载它需要通过 ServiceLoader 机制去加载驱动实现但驱动实现类却在业务 classpath 下。如果严格按双亲委派启动类加载器永远不会往下找驱动永远加载不到。解决思路就是引入线程上下文类加载器把加载请求转交给应用类加载器去处理。另一个反例是 Web 容器和应用隔离。一个容器需要管理多个应用每个应用可能有不同版本的第三方依赖如果全部交给同一个应用类加载器版本冲突会非常严重。容器通常会给每个应用创建独立的类加载器这些类加载器的父加载器指向一个公共容器加载器从而让不同应用之间的类相互隔离。打破双亲委派的关键不是技术上能不能做而是做完之后类的命名空间怎么管理。当你引入一个新的类加载器实例去加载某个类文件时这个类相对于默认加载器加载的同名类就成了两个类强转、instanceof、反射调用都会受影响。所以线上做类隔离时一定要把公共依赖提升到父加载器去加载只隔离真正需要隔离的部分。2.4 线程上下文类加载器到底是干什么的线程上下文类加载器也就是 TCCL存在在 Thread 类中默认继承创建线程时的上下文加载器。它的核心价值是给由父加载器加载的代码提供一个反向使用子加载器的入口。最典型的是各种 SPI 机制。核心接口由启动类加载器加载实现类却由应用类加载器加载。当核心代码需要加载具体实现时它不知道该用哪个加载器于是借助当前线程的 TCCL 去加载把类加载请求交还给业务侧。ServiceLoader的实现就依赖这个机制。平时写业务代码使用 TCCL 的频率确实不高但排查框架初始化问题时非常有用。比如某个扩展点加载不到实现类可以先检查当前线程的 TCCL 是不是被框架改过改成了哪个类加载器再看这个加载器能否覆盖到实现类所在的位置。多问一句当前线程的上下文加载器是谁很多诡异现象就能串起来了。3. 类加载过程中的边界细节与高频易错点这一章专门讲细节。类加载机制的难点不在于五阶段背不背得下来而在于各种边界情况下的行为是否符合直觉。3.1 数组类的加载规则数组类和普通类的加载路径差异很大。数组类本身并不通过类加载器创建而是由 JVM 在运行时直接构造。如果数组的元素是引用类型JVM 会先去加载元素类型然后再创建数组类本身。数组类的类加载器与元素类型的类加载器保持一致如果是基本类型的数组类加载器被认为是 null启动类加载器。这就解释了一个现象String[].class.getClassLoader()返回 null而自定义业务类的数组getClassLoader()返回的是应用类加载器。很多人第一次看到这个结果会愣一下以为数组类都是 null实际上规则很明显——看元素类型归属于谁。这个细节还带来一个衍生结论数组类的创建不触发元素类的初始化。Parent[] arr new Parent[10]只创建数组类Parent 本体依然不会被初始化。这也是被动引用里最经典的例子之一。3.2 主动引用与被动引用的准确边界主动引用和被动引用的边界是面试和实战都爱考的细节。前面已经列过主动引用的常见场景这里重点说被动引用的三个容易误判的例子。第一个通过子类引用父类静态字段。比如Child.xx 定义在 Parent 里编译后字节码访问的仍然是 Parent 的字段所以只有 Parent 会被初始化Child 不会。注意不要和初始化子类时父类会先初始化混淆那条规则说的是子类真正需要被初始化时父类抢先而这里 Child 压根不需要初始化。第二个定义数组。刚才已经解释过数组类不触发元素类的初始化。第三个编译期常量传播。public static final int MAX 10;这种常量在编译期就把值写进了调用方的常量池运行期调用方根本不会引用到 Constants 类。很多瘦身优化能删掉大量类就是建立在常量传播的基础上。理解这三条的价值在于当你期望某个类在启动时执行静态初始化做点事情但要确保触发路径是真正的主动引用比如直接读写一个非常量静态字段或者显式调用Class.forName。3.3 类的卸载与 Class 对象的生命周期类的卸载不是单独发生的它和类加载器的生命周期绑定。如果一个自定义类加载器没有任何强引用指向它那么它加载的所有类都进入可回收状态。反过来只要类加载器还被某个对象持有引用它加载过的所有类都不会被卸载。这对排查元空间 OOM 特别重要。如果代码里反复创建自定义类加载器去加载类但加载器对象被某个集合或框架缓存住了内存就会越涨越高。常见的解决办法是检查是谁持有了这些加载器引用把缓存清理掉让加载器连同它加载的类一起被回收。另一个和卸载相关的场景是热部署。热部署之所以能生效说到底就是旧类加载器 旧类一起被废弃新加载器 新类重新建立。只替换 class 文件而不替换加载器是达不到预期的。3.4clinit的执行顺序与潜在的初始化死锁clinit的执行顺序前文提过父类先于子类静态字段赋值和静态代码块按源码顺序执行。这里再提一个比较极端的坑类初始化死锁。假设线程 A 触发类 X 的初始化X 的静态代码块依赖类 Y 的初始化同时线程 B 触发类 Y 的初始化Y 的静态代码块依赖类 X 的初始化。由于 JVM 保证每个类的clinit只能由一个线程执行另一个线程会等待这两个线程就可能互相等成死锁。这类问题比较罕见但真出现时很吓人因为jstack里能看到成片线程 block 在类初始化帧上业务代码完全没动静。定位思路是先看有没有多个类在静态初始化期互相调用重构掉静态块中的复杂逻辑把初始化动作拆到更可控的位置。4. 类加载问题排查实录从报错到定位的完整路径大量的类加载问题都有相似的外壳真正要命的是外壳下面的真实原因。这一章整理几个高频问题的定位方法和思路。4.1 ClassNotFoundException 和 NoClassDefFoundError 的准确区分这两个名字长得像发生机制却完全不同。ClassNotFoundException是受检异常发生在主动去加载类却找不到的时候比如Class.forName、ClassLoader.loadClass、findSystemClass这些调用路径。它通常意味着类真的不在当前加载器可覆盖的范围内。NoClassDefFoundError是 Error发生时机更隐蔽类在编译期存在本应加载成功但某个指令运行到一半时再查询类却失败了。一个特别典型的场景是某个类B的静态初始化抛出异常JVM 把它标记为加载失败之后所有需要用到B的代码都不再尝试加载它直接抛NoClassDefFoundError。所以排查时如果看到NoClassDefFoundError不要只盯着当前这一条报错往前翻日志找出它第一次加载失败时抛出的异常那才是真正的根因。很多新人被这个表象误导反复重启浪费大量时间。4.2 同名类不同加载器引发的 ClassCastException类由全限定名 定义加载器唯一确定。这意味着同名的类只要加载器不同在 JVM 中就是两个类型。实际表现是两个对象从内容上看完全一致接口也一致但instanceof返回 false强转直接抛ClassCastException。我排查过一个非常有代表性的案例同一个服务里内嵌了两套框架各自创建了独立类加载器加载了一个公共库的不同版本。公共库里的接口在两个加载器里各有一份实现代码互相调用时强转失败。定位思路是先打印两边的类加载器确认归属再把公共依赖上移到同一个父加载器让两套框架共享相同定义。排查时有一个通用步骤调用object.getClass().getClassLoader()和targetClass.getClassLoader()对比这两个加载器是不是同一个实例。如果不同就需要从依赖治理角度解决而不是写代码绕过。4.3 如何快速定位类是从哪里加载的定位类加载来源最直接的方法是启动时加-verbose:class。它会打印出每个类的加载来源能看到类是从哪个 jar 或者文件路径加载进来的也能看到同一个类被重复加载的情况。新版 JDK 可以用-Xlog:classloadinfo输出格式更友好。如果服务已经跑起来了可以找当前进程用 JDK 自带工具连接上去查询指定类的加载器。实际使用中我更喜欢先通过日志输出确认类加载器类型再打印它的URLClassLoader的 URL 列表这样能直接看到它扫描了哪些路径。跨框架、跨类加载器的问题靠这个方式能很快确认类到底在哪一层。排查依赖冲突时还有个反向思路把可疑的 jar 逐个用jar命令解压检查类文件是否真的存在再对比 classpath 的加载顺序。但这是低效的更好的做法是借助依赖树工具把传递依赖捋清楚看谁把旧版本带进来了。4.4 一个最简热加载实现理解原理但不能照搬生产热部署的原理就是自定义类加载器加定时检测类文件的修改时间。每次检测到变更创建新的类加载器加载新的 byte[]新旧类因为所属加载器不同互不影响。前面那段 HotClassLoader 代码就是最简原型。public class HotDeployer { public static Object loadNewInstance(String className) throws Exception { HotClassLoader loader new HotClassLoader(); Class? clazz loader.loadClass(className); return clazz.getDeclaredConstructor().newInstance(); } }每调用一次loadNewInstance都会用一个新的加载器去加载类得到的是新版本。但生产环境要做的事情远比这个多旧对象引用的清理、容器线程的释放、加载器实例的缓存管理、序列化 id 的变化每一项都能单独写一篇。我个人的建议是生产环境用成熟的热部署方案本文这一段只用于理解原理和排查问题千万不要自己造轮子直接上生产。4.5 Class.forName 和 ClassLoader.loadClass 的行为差异Class.forName(com.xxx.A)默认会触发类的初始化也就是会执行静态块和静态字段赋值。ClassLoader.loadClass(com.xxx.A)默认不触发初始化只完成加载。很多数据库驱动在注册时需要执行静态初始化所以用 Class.forName 加载就是对的如果只做类信息的预载用 loadClass 就够了还能避免不必要的静态逻辑执行。这个差异一旦搞混线上会出现同一段代码在某个版本正常、换个版本就异常的情况。其实不是框架坏了而是类初始化的触发时机变了。5. 面试追问清单与避坑指南最后一部分给准备面试和希望系统复习的朋友一份速查清单。5.1 高频追问与答题思路围绕类加载机制的面试提问基本有几条主线双亲委派模型为什么这么设计核心类安全、避免同名类重复加载、保证一致性和安全性。双亲委派能被破坏吗哪些场景会破坏SPI、Web 容器、热部署、OSGi 式模块化都是典型场景。五个阶段各自做了什么其中哪些阶段会抛出可预期的异常Class.forName和ClassLoader.loadClass的区别是什么同一个类文件由两个类加载器加载为什么不是同一个类数组类的类加载器怎么算它会被初始化吗这些问题答得清楚说明你已经把类加载机制从背概念提升到了理解行为的层面。5.2 经典输出题初始化顺序静态初始化、实例初始化、构造函数、继承关系叠加在一起是面试里最常出的输出题。class Parent { static { System.out.println(Parent static); } { System.out.println(Parent block); } public Parent() { System.out.println(Parent cons); } } class Child extends Parent { static { System.out.println(Child static); } { System.out.println(Child block); } public Child() { System.out.println(Child cons); } }执行new Child()输出结果是Parent static Child static Parent block Parent cons Child block Child cons原因拆开看就一句话静态初始化只在类首次加载时发生且父类先于子类实例初始化阶段父类的构造器先运行然后才轮到子类的实例初始化和构造器。这个顺序掌握好大多数变体题都能稳。5.3 实战避坑清单不要随便重写loadClass。实现自定义加载器时优先重写findClass让默认委派逻辑保留。不要默认Class.forName和ClassLoader.loadClass等价。走forName前确认是否真的需要触发静态初始化。注意接口初始化的规则和抽象类不同不要拿类的逻辑硬套接口。关注自定义加载器对象的持有方避免因为加载器不可回收导致元空间持续上涨。热部署上线前一定要验证旧对象和新类的兼容性否则会埋伏下强转失败和反射混乱的风险。看到NoClassDefFoundError时先往前翻日志找到它真实的初始化失败原因而不是盯着最后一条报错反复重启。最后说点个人体会。类加载机制掌握到什么程度决定了你能把 JVM 问题排查到哪一层。很多人处理线上异常只愿意看业务日志可一旦报错来自类加载这几个字如果没有对整个链路形成画面感就很容易把问题甩给环境不对或者依赖冲突然后陷入反复重启的循环。真正把五个阶段、三个加载器、双亲委派模型串成一条线之后你会发现自己看日志的敏感度都不一样了——会主动去想这个异常是验证没过、准备阶段分配内存没对、解析阶段找不到父类、还是clinit根本没执行成功。很多时候多问自己一句它应该被哪个类加载器加载问题答案就自己浮出来了。希望这篇整理能帮你建立自己的排查感觉下次碰到类加载相关的报错不再靠重启解决。
