我一直觉得Java类加载机制是那种没出事之前完全感觉不到它存在的东西。直到有一次线上事故让我不得不把它从头到尾研究了一遍一个服务灰度后疯狂报 ClassCastException公共的 Result 类明明只有一个 Jar 包来源用反射强转却失败。我翻遍了整个依赖树也没找到第二个版本最后才意识到类在同一个 JVM 里被两个不同的类加载器各加载了一遍而 JVM 眼中的同一个类必须是类加载器 类名双重身份一致才行。这篇文章想做的是把类加载机制完整讲清楚从 .class 字节码变成真正可调用的 Java 类会经历哪些阶段双亲委派模型为什么能成为 Java 应用生态的稳定基石自定义类加载器怎么落地到热部署场景以及最常见的类加载异常到底该怎么排查。我尽量把每个关键环节背后的为什么也讲明白不只给结论。适合所有写 Java 的开发者无论你是写业务还是维护中间件迟早会碰到这里面的坑。1. 类加载机制在JVM里的地位它不是读文件那么简单1.1 一次由两个类加载器引发的线上事故先说回那次事故。这个服务在发布后某个入口接口返回的对象用反射处理时一直报 java.lang.ClassCastException被转换的类名和目标类名看起来一模一样都是 xxx.common.Result但就是转不过去。我第一反应是 Jar 包冲突于是把自己项目的依赖树翻了一遍又让同事查服务端安装目录下的 Jar结论都是只有一个 Jar没有重复版本。后来实在没办法在报错位置打印了对象和 cast 目标的 ClassLoader 以及两个 Class 对象的地址才发现两个类对象来自完全不同的加载器。原来这个服务里有一段用自定义类加载器做隔离的逻辑某个子模块的 Result 类被自己的类加载器提前加载了而入口处用的是应用类加载器两边各加载了一份同样的字节码。ClassCastException 就这么产生了——不是字节码有问题是两个类型在 JVM 看来根本不等价。这个案例给我的启发很大。我们平时说某两个类相同是有前提的必须满足三个条件类名完全相同、由同一个类加载器加载、加载的是同一份字节码。三者缺一个就算源码一模一样运行时也是两个类型。后面几乎所有类加载相关的排查到最后都会回到这个判断上。1.2 类加载机制到底解决了什么问题那么类加载机制到底在做什么一句话概括它负责回答一个类的字节码从哪来、能不能用、什么时候初始化、怎么变成 JVM 里可以操作的类型这一连串问题。很多人以为类加载就是读取 .class 文件放进内存其实没那么简单。JVM 规范规定类加载要经历加载、连接、初始化三大阶段连接阶段里又细分了验证、准备、解析三步。每一步解决的问题都不一样加载解决字节码从哪里来可以是文件、Jar、网络甚至运行时动态生成的字节码验证解决这段字节码合不合法防止恶意或不规范的字节码进来搞破坏准备解决静态变量该在哪儿躺着提前为类变量分配内存并赋默认值解析解决代码里的符号引用怎么变成真实内存地址初始化解决静态块和静态字段的赋值逻辑什么时候执行。除了这些阶段类加载机制还包含了由谁来加载的规则也就是类加载器体系。一个类由哪个类加载器加载直接决定了它在 JVM 里的身份唯一性也决定了它和其他类的可见关系。理解了这条主线后面看双亲委派、自定义加载器、类冲突问题就会清晰很多。2. 从字节码到可调用类一个Java类的完整生命周期2.1 加载字节流怎么变成Class对象一个类被用到的时候JVM 才懒洋洋地去加载它而不是启动时把所有 class 都读进内存。加载阶段做三件事通过类的全限定名获取描述这个类的二进制字节流把字节流中的静态存储结构转换为方法区里的运行时数据结构在堆里生成一个代表这个类的 java.lang.Class 对象作为外界访问该类型的入口。这里的全限定名就是带包名的完整类名比如 java.lang.String。二进制字节流的来源非常多样最常见的自然是 .class 文件但也可以是某些容器从部署包里解出来的 class或者从网络下载、数据库读取甚至动态生成。这里顺便埋个伏笔既然字节流没有规定只能从文件来那加载本身就成为可以自定义扩展的一步这正是自定义类加载器发挥作用的地方。有一点要注意JVM 对加载时机是有讲究的。一个类没有被主动使用时JVM 可能整个生命周期都不会加载它这是懒加载。理解了这一点你就知道为什么有些类其实已经缺失了但应用启动时根本不报错要到某个请求走到那行代码才突然抛 NoClassDefFoundError。这种迟到的报错常常让人措手不及。2.2 连接验证、准备、解析这三关分别拦谁加载完成之后进入连接阶段。连接的第一步是验证目的就是检查字节流是否合法防止不怀好意的字节码绕过 Java 语法和 JVM 规范。验证包含文件格式验证、元数据验证、字节码验证和符号引用验证。文件格式验证会检查是否以 0xCAFEBABE 这个魔数开头、主次版本号是否受支持元数据验证会检查类的父类是否存在、是否实现了要实现的接口字节码验证则通过数据流和控制流分析来确保操作码不会破坏虚拟机栈。听着很繁琐但实际大多数 class 都来自正常编译器验证一般不会出问题。而且现代 JVM 对于直接由自己加载器生成、已经验证过的框架字节码会有一些简化和信任路径。我自己见过的验证失败基本都是手工改字节码或者小众字节码生成库版本不匹配导致的。第二步是准备。这个阶段为类变量也就是 static 字段分配内存并设置初始值。注意这里说的是默认值不是代码里写的值。比如static int x 5在准备阶段 x 先被设为 0到初始化阶段才会真正赋值为 5。不过有一个例外static final 修饰的常量如果编译期就能确定值JVM 会用 ConstantValue 属性在准备阶段直接赋值不走初始化这一道。第三步是解析。JVM 会把常量池里的符号引用替换为直接引用。你可以把符号引用理解成代码里写的某个类全限定名字段名方法名这种文本描述直接引用则是真正指向内存地址或者偏移量的引用。解析的动作有时会推迟到某个符号首次被实际使用时才触发不必在连接阶段全部完成所以有的类加载后解析并没有立刻做完。2.3 初始化clinit与什么时候才算主动使用初始化是这个生命周期里最容易被忽视、也最容易出事的一步。它执行的是clinit方法也就是类构造器里面汇聚了所有静态变量的赋值语句和静态代码块。JVM 会保证clinit在单线程环境下执行并且如果这个类有父类父类的clinit一定先执行完。多人协作时常见的 bug 就是静态块里依赖外部资源一旦资源不可用初始化就抛异常而这个异常往往不是立刻显现而是等到某个线程第一次创建该类的实例时才突然冒出来。那么什么时候才算主动使用会触发初始化new 一个对象、通过反射访问类、读写某个类的静态字段、调用静态方法、初始化一个类前先初始化其父类以及 main 方法所在的启动类等等都算主动使用。反过来还有一些看着像用了实际不算主动引用的场景通过子类去引用父类的静态字段子类不会被初始化用一个类的数组声明数组变量这个类不会被初始化引用 static final 常量也不会因为常量已经在编译期被内联到了使用方代码里。最后一个知识点在热部署场景里特别关键。我之后讲热部署时还会提到如果一个类的 static final 常量被另一个类在编译期复制走了那你就算把这个类的 class 文件替换成新版本使用方还是旧常量因为字节码层面它压根没有再引用你。这个编译期内联行为会让很多第一次做热部署的人百思不得其解。下面是类加载五个阶段的简要对照方便你快速回忆完整链条阶段核心问题典型动作失败表现加载字节码从哪来读取 class/Jar/网络字节流生成 Class 对象ClassNotFoundException验证字节码合法吗检查魔数、版本、元数据、字节码语义VerifyError、ClassFormatError准备静态变量放哪分配内存赋默认零值多发生在内存不足时解析符号引用指到哪常量池符号替换为直接引用NoSuchFieldError、NoSuchMethodError初始化静态逻辑何时跑执行clinit赋真实初始值ExceptionInInitializerError3. 双亲委派模型Java生态稳定运行的地基3.1 类加载器的三层结构以及JDK9之后的变化默认情况下JVM 里的类加载器分成三层。最顶层是启动类加载器它负责加载 JDK 自身的核心类JDK 安装目录下的 lib 以及被 -Xbootclasspath 指定的类都归它管。在 HotSpot 虚拟机里这个加载器是 C 实现的对应 Java 视角里看到的 null所以你在代码里打印启动类加载器的 toString 会得到 null。往下是扩展类加载器JDK 9 以后改名为平台类加载器负责加载 JDK 的扩展模块和平台相关类。再往下是应用类加载器也叫系统类加载器它负责加载 classpath包括环境变量里的 CLASSPATH、项目依赖的所有 Jar下的类。我们平时写的代码默认都是它加载的。这三层有明确的父子关系而且这个父子关系是通过组合而不是继承实现的子加载器内部持有 parent 引用。JDK 9 引入模块化之后类加载器体系有了一些调整名字也换了但双亲委派的总体框架还在平台类加载器取代了原来扩展类加载器的位置。对我这种经常排查类冲突的人来说核心认知没有变你仍然可以从ClassLoader.getParent()看出层级关系依然可以通过自定义加载器扩展体系。按加载范围快速归纳就是下面这张表类加载器加载范围Java 视角的 parent启动类加载器JDK 核心类库nullC 实现平台/扩展类加载器JDK 扩展模块、平台类启动类加载器应用/系统类加载器classpath 下的所有类平台/扩展类加载器自定义类加载器自己指定的目录/字节码来源通常挂到应用类加载器或其父级3.2 loadClass源码一次由父到子的委派双亲委派模型的逻辑核心在java.lang.ClassLoader.loadClass()方法里。整个顺序大概是先调用findLoadedClass()查一下这个类是否已经被当前加载器加载过如果没有而且 parent 存在就调用 parent.loadClass()把加载请求往上抛父加载器也按照同样逻辑继续向上委派。只有等所有父级都加载失败抛回 ClassNotFoundException当前加载器才会调用自己的 findClass() 去真正尝试加载。为什么要设计成父优先而不是自己优先直接说结论是两个原因。第一避免同一个类被重复加载。如果没有委派应用类加载器和自定义加载器可能各加载一遍 java.lang.String那代码还能不能愉快地运行就要打问号了。第二保证核心类不被覆盖。比如有人往 classpath 里塞了一个伪造的 java.lang.String如果自己优先这个伪造类可能就被加载了。但委派模型下请求会一路送到启动类加载器核心类由它加载并且只有一份安全性就保住了。这里有个很多人误解的细节所谓双亲其实指的是父加载器并不存在两个亲。由于层级都是单一父节点数据结构翻译成双亲纯粹是沿用了以前的中文翻译习惯。你在源码里看 loadClass 的参数和 parent 字段就明白了。3.3 打破双亲委派会发生什么虽然双亲委派是默认规则但它不是强制的。类加载器完全可以通过重写 loadClass 方法改变行为。最有名的反例是某些 Servlet 容器它们会打破父优先让应用自己的类加载器优先加载部署包里的类这样同一个应用内部的库版本就可以和容器全局依赖隔离。这就是典型的子优先策略。打破双亲委派能解决隔离问题但也带来了副作用同一个 Jar 如果被容器全局类加载器和应用类加载器各加载一次就会出现两份类。跨越这两个加载器传递对象时就会遇到我开头说的那种 ClassCastException或者方法签名不匹配的 NoSuchMethodError。所以你会看到Servlet 容器里多年的最佳实践都在教育开发者公共的 API 依赖要放在全局区应用私有的实现放应用区避免把同一个类加载到两个区域。我前几年做插件化方案时也遇到过类似困境。每个插件一个类加载器插件之间如果共享同一个基础库就必须靠父加载器统一加载否则两个插件里的同一个类型根本无法互相识别。这是理解类加载机制后必须接受的事实没有绝对的打破或遵守只有根据场景选策略。4. 自定义类加载器实战加密字节码与热部署落地4.1 什么场景必须自己写类加载器自定义类加载器听起来很高大上实际应用场景非常明确。第一个场景是字节码加密。为了防止 class 文件被直接反编译很多商用软件会把 class 文件加密存放运行时由自定义加载器读入后再解密成标准字节码交给 defineClass。第二个场景是热部署。服务不停机替换某个模块的类实现时需要一个新的类加载器去加载新版本因为同一个类加载器无法重新定义同名类。第三个场景是动态生成类的加载比如代理类、字节码增强等这些动态 class 需要一个入口被加载进 JVM。第四个场景是模块隔离也就是前面插件化的例子。判断自己是否需要自定义加载器的标准很简单默认的应用类加载器能不能加载到你想加载的字节码如果字节码来源不在 classpath 里或者你想让同一份 class 在不同隔离空间里各有一份那就必须自定义。4.2 findClass骨架与defineClass的边界自定义加载器的核心切入点就是重写 findClass 方法。前面说了加载请求会先走双亲委派父加载器加载失败后最终会调到这里。下面是一个非常典型的实现骨架public class PathClassLoader extends ClassLoader { private final String classRoot; public PathClassLoader(String classRoot, ClassLoader parent) { super(parent); this.classRoot classRoot; } Override protected Class? findClass(String name) throws ClassNotFoundException { String path classRoot / name.replace(., /) .class; try (FileInputStream in new FileInputStream(path)) { byte[] bytes in.readAllBytes(); return defineClass(name, bytes, 0, bytes.length); } catch (IOException e) { throw new ClassNotFoundException(cannot load class name, e); } } }这段代码有几个细节值得说明。一是只重写 findClass不重写 loadClass。这样做的目的是保住双亲委派能由父级加载的类仍然由父级加载只有父级加载不到时才落到你这里。如果重写 loadClass 并且不走 parent等于直接打破双亲委派除非你有隔离需求否则不建议这么干。二是 defineClass 是 native 方法它把字节码转换成 Class 对象。需要注意的是defineClass 并不会校验类的来源只要你给它的字节码符合 JVM 规范它就会定义。所以如果你加载的是不可信来源的字节码JVM 后续的验证阶段会承担一部分安全工作但代码逻辑的合法性你仍然自己负责。三是关于 resolveClass。很多示例里会调用resolveClass(c)这一步是触发类的连接。实际上 defineClass 之后类已经可以被使用resolveClass 一般不是必须的连接的解析动作会在首次使用时触发。不调完全没问题不用给自己增加负担。4.3 简易热部署实现与必须避开的三个坑光会写 findClass 还不够热部署的完整逻辑是用新类加载器加载新版本并用新对象替换旧对象。最简单的一套做法定义业务接口版本文件放特定目录每次发布把新版 class 放到另一个版本号子目录要切换时 new 一个类加载器去加载这个目录然后通过反射构建新实例再把旧实例从缓存里替换掉。核心流程只有三步构建新加载器、加载目标类、替换引用。但实测中坑非常多我按踩的深度排一下。第一个坑是旧类加载器无法被回收。新版本切换后如果旧对象还被某个容器强引用着对应的旧类加载器就始终活着而它加载过的一整批类都留在元空间里反复发布几次后容易出现元空间内存溢出。解决办法是切换后主动释放强引用最好在框架层面设计成版本号索引 弱引用缓存的结构保证旧加载器可以被 GC。第二个坑是常量内联。前面说的 static final 常量并发症在这里会放大如果版本 A 引用了某个配置类里的常量版本 B 改了常量值但 A 的字节码已经内联了旧值那么替换配置类本身毫无作用必须连带重新编译所有引用了这个常量的类。线上做热部署时这个坑最容易让明明替换了文件却看不到效果。第三个坑是跨加载器的类型转换。热部署后新旧两个类虽然在方法结构上完全一样但类型身份不同。如果你在容器代码里直接写强转(OldVersionClass) newInstance会直接 ClassCastException。所以热部署接口设计上必须避免直接依赖具体类而是面向共同接口或者用反射、Map 传递数据。这也是为什么成熟的热部署框架都强调接口隔离。5. 类加载异常排查两个最让人失眠的报错5.1 ClassNotFoundException与NoClassDefFoundError的本质区别类加载异常里最常见的两个报错看起来像兄弟本质完全不同。先看一组对比维度ClassNotFoundExceptionNoClassDefFoundError类型Exception受检异常Error错误触发方式Class.forName、loadClass 等显式反射动作运行时有一段代码引用了某个类但该类加载/初始化失败含义按全限定名在所有可触达的加载器里都没找到定义类曾经被引用过但运行时它的 Class 对象没准备好常见原因类名写错、依赖包缺失、classpath 不对依赖缺失、静态初始化抛异常、类加载器范围不对排查重点类名、classpath、加载器可见性Caused by 链上的根因特别是初始化失败ClassNotFoundException 的典型场景是手写Class.forName(com.example.Driver)时把类名拼错或者依赖 Jar 没打进去。NoClassDefFoundError 则更隐蔽一种是编译期存在、运行期某个类文件从 classpath 里消失了另一种是类本身可以被找到但它的静态初始化阶段抛了异常导致后续任何使用它的代码都会以 NoClassDefFoundError 形式报错。很多人看到类文件明明在却一直报 NoClassDefFoundError其实就是没去翻 Caused by 链上的初始化失败这个根因。这两个报错的排查方向也因此完全不一样前者去查类名、查 classpath、查加载器范围后者要先去定位底层有没有一个更原始的异常查静态块里干了什么、依赖的类是否完整。5.2 依赖重复与NoSuchMethodError类加载冲突的常见面孔除了上面两个报错类加载冲突还经常以 NoSuchMethodError、LinkageError 的面孔出现。这通常和依赖重复有关同一个类出现在多个 Jar 里或者一个 Jar 的不同版本被打进最终的 classpath。编译时你对着的是新版本的类运行时有另一个类加载器先加载了旧版本旧版本里没有某个方法运行到调用处就抛 NoSuchMethodError。我曾经排查过一个服务里 NoSuchMethodError 的问题。调用方引用的库方法签名是对的但还是报错最后用工具打印出实际加载到的类文件头部才确认class 文件是最旧的版本。问题是某个聚合依赖把旧版本传递进来了而它又恰好在 classpath 中被优先找到。解决方向就两个用依赖管理工具的统一版本机制把版本对齐或者在最终打 Jar 时显式排除掉不需要的旧版本保证生产环境 classpath 里每个类只有一份。排查这个家族问题的通用思路是先确认代码里调用的方法/字段真的存在于运行时加载到的那个类里。这两个对象很可能不是同一个。你要顺着谁加载了它、从哪个来源加载的去查而不是被报错信息里的类名唬住。5.3 一次线上报错的完整排查链路分享一次印象比较深的排查。某个查询接口在压测时突然开始报 NoClassDefFoundError但应用刚启动时运行得好好的。我当时的排查顺序是先看异常堆栈的 Caused by 部分发现根因是一个第三方工具类的静态块里连不上某个外部服务初始化抛了异常。再往回看为什么以前没触发因为那个工具类之前没有被任意请求路径触达属于延迟加载等到压测第一次走到这段路径时才触发初始化。于是修复方向就清晰了——不是依赖缺失而是静态初始化依赖的资源不可靠。调整方式是把那个工具类的初始化时机提前到启动阶段并且加上降级保护避免运行期突然初始化失败。这条链路里最有价值的一步是别把 NoClassDefFoundError 当成品名问题第一时间往 Caused by 链里挖。类加载异常经常只是一个表象真正的病灶藏在静态块初始化失败、方法区空间不足、依赖版本错位这些地方。另外可以多用启动参数-verbose:class或者 jcmd 加 Java 自带诊断工具直接看某个类到底是从哪个 Jar、被哪个加载器加载的这比对着报错猜效率高得多。6. 线程上下文类加载器双亲委派体系里的反向通道6.1 SPI场景下的委派失灵与破解思路双亲委派模型看似完美但在 SPI服务提供者接口场景下会卡住。以 JDBC 为例java.sql 包下的 DriverManager 是 JDK 核心类库按双亲委派它由启动类加载器加载而具体数据库驱动的实现则躺在应用 classpath 里由应用类加载器加载。当 DriverManager 内部想通过 Class.forName 加载驱动类时请求顺着启动类加载器向上走可启动类加载器根本看不到应用 classpath结果就是找不到类驱动永远无法加载。Java 设计者给出的解决方案是线程上下文类加载器。每个线程可以设置一个 contextClassLoader核心类库在需要跨加载器加载外部实现时会主动使用当前线程的 contextClassLoader 来加载相当于显式留了一条反方向的通道。DriverManager 就通过Thread.currentThread().getContextClassLoader()来加载具体的驱动类。这样既保留了核心类只加载一份的隔离性又让核心代码有能力触达应用侧的实现。理解了这个设计就不难理解为什么很多中间件里都有SPI 加载器的说法它们本质上都是利用线程上下文类加载器去突破双亲委派的边界把由谁加载的控制权交给部署方。6.2 线程上下文类加载器的使用姿势与风险日常写代码时你很少需要主动碰线程上下文类加载器但框架层经常用。如果你确实要用基本姿势是ClassLoader contextCL Thread.currentThread().getContextClassLoader(); try { Class? clazz Class.forName(某个SPI实现类, true, contextCL); // 通过 clazz 反射构造实例 } finally { // 如果临时替换过上下文加载器务必还原 }这里有一个非常容易忽略的风险线程上下文类加载器是线程级的全局状态。如果你在某段代码里临时把当前线程的 contextClassLoader 换成别的加载器而忘记在 finally 里恢复轻则导致后续业务代码用它加载出完全不同的类版本重则引发一系列诡异的类冲突。我看到过线上事故就是这么来的一个第三方组件在异步线程里修改了上下文加载器随后业务代码按新加载器加载了一堆类类身份全部错乱。另一个常见问题是线程池场景下 contextClassLoader 的传递。默认新建线程会继承父线程的上下文类加载器但线程池里的线程是复用的如果业务代码不主动在任务提交时把 contextClassLoader 传递到任务上下文那么池中线程的上下文加载器可能停在一个过期的版本上导致后续的 SPI 加载行为不符合预期。很多讲究的框架都会在提交任务时显式保存并恢复上下文类加载器原因就在这。最后想给一个具体建议如果你在排查类加载问题时发现某些类是被莫名其妙的加载器加载的第一反应就去看当前线程的 contextClassLoader 有没有被临时改过。这个字段看不见摸不着却是很多跨加载器 bug 的源头。打印日志时带上一行 currentThread 的 getContextClassLoader 和调用处的 getClassLoader往往能一眼定位问题。我做类加载相关的项目从第一次踩 ClassCastException 的坑到现在最大的感受是这个机制的设计其实非常自洽双亲委派保证核心类和业务类不互相污染线程上下文类加载器又给跨加载器协作留了口子自定义类加载器则把加载变成了可编程的环节。遇到类加载问题别慌先确认三层身份——字节码来源、加载器是谁、初始化状态是否正常大部分问题都能在十分钟内定位。如果环境允许平时多看一眼类加载日志、保持依赖版本干净比临时抱佛脚查报错要省心得多。 
长河君 · 2026/10/13 23:58:01 · 阅读 1.2k Java类加载机制全解：从双亲委派到热部署与异常排查
我一直觉得Java类加载机制是那种没出事之前完全感觉不到它存在的东西。直到有一次线上事故让我不得不把它从头到尾研究了一遍一个服务灰度后疯狂报 ClassCastException公共的 Result 类明明只有一个 Jar 包来源用反射强转却失败。我翻遍了整个依赖树也没找到第二个版本最后才意识到类在同一个 JVM 里被两个不同的类加载器各加载了一遍而 JVM 眼中的同一个类必须是类加载器 类名双重身份一致才行。这篇文章想做的是把类加载机制完整讲清楚从 .class 字节码变成真正可调用的 Java 类会经历哪些阶段双亲委派模型为什么能成为 Java 应用生态的稳定基石自定义类加载器怎么落地到热部署场景以及最常见的类加载异常到底该怎么排查。我尽量把每个关键环节背后的为什么也讲明白不只给结论。适合所有写 Java 的开发者无论你是写业务还是维护中间件迟早会碰到这里面的坑。1. 类加载机制在JVM里的地位它不是读文件那么简单1.1 一次由两个类加载器引发的线上事故先说回那次事故。这个服务在发布后某个入口接口返回的对象用反射处理时一直报 java.lang.ClassCastException被转换的类名和目标类名看起来一模一样都是 xxx.common.Result但就是转不过去。我第一反应是 Jar 包冲突于是把自己项目的依赖树翻了一遍又让同事查服务端安装目录下的 Jar结论都是只有一个 Jar没有重复版本。后来实在没办法在报错位置打印了对象和 cast 目标的 ClassLoader 以及两个 Class 对象的地址才发现两个类对象来自完全不同的加载器。原来这个服务里有一段用自定义类加载器做隔离的逻辑某个子模块的 Result 类被自己的类加载器提前加载了而入口处用的是应用类加载器两边各加载了一份同样的字节码。ClassCastException 就这么产生了——不是字节码有问题是两个类型在 JVM 看来根本不等价。这个案例给我的启发很大。我们平时说某两个类相同是有前提的必须满足三个条件类名完全相同、由同一个类加载器加载、加载的是同一份字节码。三者缺一个就算源码一模一样运行时也是两个类型。后面几乎所有类加载相关的排查到最后都会回到这个判断上。1.2 类加载机制到底解决了什么问题那么类加载机制到底在做什么一句话概括它负责回答一个类的字节码从哪来、能不能用、什么时候初始化、怎么变成 JVM 里可以操作的类型这一连串问题。很多人以为类加载就是读取 .class 文件放进内存其实没那么简单。JVM 规范规定类加载要经历加载、连接、初始化三大阶段连接阶段里又细分了验证、准备、解析三步。每一步解决的问题都不一样加载解决字节码从哪里来可以是文件、Jar、网络甚至运行时动态生成的字节码验证解决这段字节码合不合法防止恶意或不规范的字节码进来搞破坏准备解决静态变量该在哪儿躺着提前为类变量分配内存并赋默认值解析解决代码里的符号引用怎么变成真实内存地址初始化解决静态块和静态字段的赋值逻辑什么时候执行。除了这些阶段类加载机制还包含了由谁来加载的规则也就是类加载器体系。一个类由哪个类加载器加载直接决定了它在 JVM 里的身份唯一性也决定了它和其他类的可见关系。理解了这条主线后面看双亲委派、自定义加载器、类冲突问题就会清晰很多。2. 从字节码到可调用类一个Java类的完整生命周期2.1 加载字节流怎么变成Class对象一个类被用到的时候JVM 才懒洋洋地去加载它而不是启动时把所有 class 都读进内存。加载阶段做三件事通过类的全限定名获取描述这个类的二进制字节流把字节流中的静态存储结构转换为方法区里的运行时数据结构在堆里生成一个代表这个类的 java.lang.Class 对象作为外界访问该类型的入口。这里的全限定名就是带包名的完整类名比如 java.lang.String。二进制字节流的来源非常多样最常见的自然是 .class 文件但也可以是某些容器从部署包里解出来的 class或者从网络下载、数据库读取甚至动态生成。这里顺便埋个伏笔既然字节流没有规定只能从文件来那加载本身就成为可以自定义扩展的一步这正是自定义类加载器发挥作用的地方。有一点要注意JVM 对加载时机是有讲究的。一个类没有被主动使用时JVM 可能整个生命周期都不会加载它这是懒加载。理解了这一点你就知道为什么有些类其实已经缺失了但应用启动时根本不报错要到某个请求走到那行代码才突然抛 NoClassDefFoundError。这种迟到的报错常常让人措手不及。2.2 连接验证、准备、解析这三关分别拦谁加载完成之后进入连接阶段。连接的第一步是验证目的就是检查字节流是否合法防止不怀好意的字节码绕过 Java 语法和 JVM 规范。验证包含文件格式验证、元数据验证、字节码验证和符号引用验证。文件格式验证会检查是否以 0xCAFEBABE 这个魔数开头、主次版本号是否受支持元数据验证会检查类的父类是否存在、是否实现了要实现的接口字节码验证则通过数据流和控制流分析来确保操作码不会破坏虚拟机栈。听着很繁琐但实际大多数 class 都来自正常编译器验证一般不会出问题。而且现代 JVM 对于直接由自己加载器生成、已经验证过的框架字节码会有一些简化和信任路径。我自己见过的验证失败基本都是手工改字节码或者小众字节码生成库版本不匹配导致的。第二步是准备。这个阶段为类变量也就是 static 字段分配内存并设置初始值。注意这里说的是默认值不是代码里写的值。比如static int x 5在准备阶段 x 先被设为 0到初始化阶段才会真正赋值为 5。不过有一个例外static final 修饰的常量如果编译期就能确定值JVM 会用 ConstantValue 属性在准备阶段直接赋值不走初始化这一道。第三步是解析。JVM 会把常量池里的符号引用替换为直接引用。你可以把符号引用理解成代码里写的某个类全限定名字段名方法名这种文本描述直接引用则是真正指向内存地址或者偏移量的引用。解析的动作有时会推迟到某个符号首次被实际使用时才触发不必在连接阶段全部完成所以有的类加载后解析并没有立刻做完。2.3 初始化clinit与什么时候才算主动使用初始化是这个生命周期里最容易被忽视、也最容易出事的一步。它执行的是clinit方法也就是类构造器里面汇聚了所有静态变量的赋值语句和静态代码块。JVM 会保证clinit在单线程环境下执行并且如果这个类有父类父类的clinit一定先执行完。多人协作时常见的 bug 就是静态块里依赖外部资源一旦资源不可用初始化就抛异常而这个异常往往不是立刻显现而是等到某个线程第一次创建该类的实例时才突然冒出来。那么什么时候才算主动使用会触发初始化new 一个对象、通过反射访问类、读写某个类的静态字段、调用静态方法、初始化一个类前先初始化其父类以及 main 方法所在的启动类等等都算主动使用。反过来还有一些看着像用了实际不算主动引用的场景通过子类去引用父类的静态字段子类不会被初始化用一个类的数组声明数组变量这个类不会被初始化引用 static final 常量也不会因为常量已经在编译期被内联到了使用方代码里。最后一个知识点在热部署场景里特别关键。我之后讲热部署时还会提到如果一个类的 static final 常量被另一个类在编译期复制走了那你就算把这个类的 class 文件替换成新版本使用方还是旧常量因为字节码层面它压根没有再引用你。这个编译期内联行为会让很多第一次做热部署的人百思不得其解。下面是类加载五个阶段的简要对照方便你快速回忆完整链条阶段核心问题典型动作失败表现加载字节码从哪来读取 class/Jar/网络字节流生成 Class 对象ClassNotFoundException验证字节码合法吗检查魔数、版本、元数据、字节码语义VerifyError、ClassFormatError准备静态变量放哪分配内存赋默认零值多发生在内存不足时解析符号引用指到哪常量池符号替换为直接引用NoSuchFieldError、NoSuchMethodError初始化静态逻辑何时跑执行clinit赋真实初始值ExceptionInInitializerError3. 双亲委派模型Java生态稳定运行的地基3.1 类加载器的三层结构以及JDK9之后的变化默认情况下JVM 里的类加载器分成三层。最顶层是启动类加载器它负责加载 JDK 自身的核心类JDK 安装目录下的 lib 以及被 -Xbootclasspath 指定的类都归它管。在 HotSpot 虚拟机里这个加载器是 C 实现的对应 Java 视角里看到的 null所以你在代码里打印启动类加载器的 toString 会得到 null。往下是扩展类加载器JDK 9 以后改名为平台类加载器负责加载 JDK 的扩展模块和平台相关类。再往下是应用类加载器也叫系统类加载器它负责加载 classpath包括环境变量里的 CLASSPATH、项目依赖的所有 Jar下的类。我们平时写的代码默认都是它加载的。这三层有明确的父子关系而且这个父子关系是通过组合而不是继承实现的子加载器内部持有 parent 引用。JDK 9 引入模块化之后类加载器体系有了一些调整名字也换了但双亲委派的总体框架还在平台类加载器取代了原来扩展类加载器的位置。对我这种经常排查类冲突的人来说核心认知没有变你仍然可以从ClassLoader.getParent()看出层级关系依然可以通过自定义加载器扩展体系。按加载范围快速归纳就是下面这张表类加载器加载范围Java 视角的 parent启动类加载器JDK 核心类库nullC 实现平台/扩展类加载器JDK 扩展模块、平台类启动类加载器应用/系统类加载器classpath 下的所有类平台/扩展类加载器自定义类加载器自己指定的目录/字节码来源通常挂到应用类加载器或其父级3.2 loadClass源码一次由父到子的委派双亲委派模型的逻辑核心在java.lang.ClassLoader.loadClass()方法里。整个顺序大概是先调用findLoadedClass()查一下这个类是否已经被当前加载器加载过如果没有而且 parent 存在就调用 parent.loadClass()把加载请求往上抛父加载器也按照同样逻辑继续向上委派。只有等所有父级都加载失败抛回 ClassNotFoundException当前加载器才会调用自己的 findClass() 去真正尝试加载。为什么要设计成父优先而不是自己优先直接说结论是两个原因。第一避免同一个类被重复加载。如果没有委派应用类加载器和自定义加载器可能各加载一遍 java.lang.String那代码还能不能愉快地运行就要打问号了。第二保证核心类不被覆盖。比如有人往 classpath 里塞了一个伪造的 java.lang.String如果自己优先这个伪造类可能就被加载了。但委派模型下请求会一路送到启动类加载器核心类由它加载并且只有一份安全性就保住了。这里有个很多人误解的细节所谓双亲其实指的是父加载器并不存在两个亲。由于层级都是单一父节点数据结构翻译成双亲纯粹是沿用了以前的中文翻译习惯。你在源码里看 loadClass 的参数和 parent 字段就明白了。3.3 打破双亲委派会发生什么虽然双亲委派是默认规则但它不是强制的。类加载器完全可以通过重写 loadClass 方法改变行为。最有名的反例是某些 Servlet 容器它们会打破父优先让应用自己的类加载器优先加载部署包里的类这样同一个应用内部的库版本就可以和容器全局依赖隔离。这就是典型的子优先策略。打破双亲委派能解决隔离问题但也带来了副作用同一个 Jar 如果被容器全局类加载器和应用类加载器各加载一次就会出现两份类。跨越这两个加载器传递对象时就会遇到我开头说的那种 ClassCastException或者方法签名不匹配的 NoSuchMethodError。所以你会看到Servlet 容器里多年的最佳实践都在教育开发者公共的 API 依赖要放在全局区应用私有的实现放应用区避免把同一个类加载到两个区域。我前几年做插件化方案时也遇到过类似困境。每个插件一个类加载器插件之间如果共享同一个基础库就必须靠父加载器统一加载否则两个插件里的同一个类型根本无法互相识别。这是理解类加载机制后必须接受的事实没有绝对的打破或遵守只有根据场景选策略。4. 自定义类加载器实战加密字节码与热部署落地4.1 什么场景必须自己写类加载器自定义类加载器听起来很高大上实际应用场景非常明确。第一个场景是字节码加密。为了防止 class 文件被直接反编译很多商用软件会把 class 文件加密存放运行时由自定义加载器读入后再解密成标准字节码交给 defineClass。第二个场景是热部署。服务不停机替换某个模块的类实现时需要一个新的类加载器去加载新版本因为同一个类加载器无法重新定义同名类。第三个场景是动态生成类的加载比如代理类、字节码增强等这些动态 class 需要一个入口被加载进 JVM。第四个场景是模块隔离也就是前面插件化的例子。判断自己是否需要自定义加载器的标准很简单默认的应用类加载器能不能加载到你想加载的字节码如果字节码来源不在 classpath 里或者你想让同一份 class 在不同隔离空间里各有一份那就必须自定义。4.2 findClass骨架与defineClass的边界自定义加载器的核心切入点就是重写 findClass 方法。前面说了加载请求会先走双亲委派父加载器加载失败后最终会调到这里。下面是一个非常典型的实现骨架public class PathClassLoader extends ClassLoader { private final String classRoot; public PathClassLoader(String classRoot, ClassLoader parent) { super(parent); this.classRoot classRoot; } Override protected Class? findClass(String name) throws ClassNotFoundException { String path classRoot / name.replace(., /) .class; try (FileInputStream in new FileInputStream(path)) { byte[] bytes in.readAllBytes(); return defineClass(name, bytes, 0, bytes.length); } catch (IOException e) { throw new ClassNotFoundException(cannot load class name, e); } } }这段代码有几个细节值得说明。一是只重写 findClass不重写 loadClass。这样做的目的是保住双亲委派能由父级加载的类仍然由父级加载只有父级加载不到时才落到你这里。如果重写 loadClass 并且不走 parent等于直接打破双亲委派除非你有隔离需求否则不建议这么干。二是 defineClass 是 native 方法它把字节码转换成 Class 对象。需要注意的是defineClass 并不会校验类的来源只要你给它的字节码符合 JVM 规范它就会定义。所以如果你加载的是不可信来源的字节码JVM 后续的验证阶段会承担一部分安全工作但代码逻辑的合法性你仍然自己负责。三是关于 resolveClass。很多示例里会调用resolveClass(c)这一步是触发类的连接。实际上 defineClass 之后类已经可以被使用resolveClass 一般不是必须的连接的解析动作会在首次使用时触发。不调完全没问题不用给自己增加负担。4.3 简易热部署实现与必须避开的三个坑光会写 findClass 还不够热部署的完整逻辑是用新类加载器加载新版本并用新对象替换旧对象。最简单的一套做法定义业务接口版本文件放特定目录每次发布把新版 class 放到另一个版本号子目录要切换时 new 一个类加载器去加载这个目录然后通过反射构建新实例再把旧实例从缓存里替换掉。核心流程只有三步构建新加载器、加载目标类、替换引用。但实测中坑非常多我按踩的深度排一下。第一个坑是旧类加载器无法被回收。新版本切换后如果旧对象还被某个容器强引用着对应的旧类加载器就始终活着而它加载过的一整批类都留在元空间里反复发布几次后容易出现元空间内存溢出。解决办法是切换后主动释放强引用最好在框架层面设计成版本号索引 弱引用缓存的结构保证旧加载器可以被 GC。第二个坑是常量内联。前面说的 static final 常量并发症在这里会放大如果版本 A 引用了某个配置类里的常量版本 B 改了常量值但 A 的字节码已经内联了旧值那么替换配置类本身毫无作用必须连带重新编译所有引用了这个常量的类。线上做热部署时这个坑最容易让明明替换了文件却看不到效果。第三个坑是跨加载器的类型转换。热部署后新旧两个类虽然在方法结构上完全一样但类型身份不同。如果你在容器代码里直接写强转(OldVersionClass) newInstance会直接 ClassCastException。所以热部署接口设计上必须避免直接依赖具体类而是面向共同接口或者用反射、Map 传递数据。这也是为什么成熟的热部署框架都强调接口隔离。5. 类加载异常排查两个最让人失眠的报错5.1 ClassNotFoundException与NoClassDefFoundError的本质区别类加载异常里最常见的两个报错看起来像兄弟本质完全不同。先看一组对比维度ClassNotFoundExceptionNoClassDefFoundError类型Exception受检异常Error错误触发方式Class.forName、loadClass 等显式反射动作运行时有一段代码引用了某个类但该类加载/初始化失败含义按全限定名在所有可触达的加载器里都没找到定义类曾经被引用过但运行时它的 Class 对象没准备好常见原因类名写错、依赖包缺失、classpath 不对依赖缺失、静态初始化抛异常、类加载器范围不对排查重点类名、classpath、加载器可见性Caused by 链上的根因特别是初始化失败ClassNotFoundException 的典型场景是手写Class.forName(com.example.Driver)时把类名拼错或者依赖 Jar 没打进去。NoClassDefFoundError 则更隐蔽一种是编译期存在、运行期某个类文件从 classpath 里消失了另一种是类本身可以被找到但它的静态初始化阶段抛了异常导致后续任何使用它的代码都会以 NoClassDefFoundError 形式报错。很多人看到类文件明明在却一直报 NoClassDefFoundError其实就是没去翻 Caused by 链上的初始化失败这个根因。这两个报错的排查方向也因此完全不一样前者去查类名、查 classpath、查加载器范围后者要先去定位底层有没有一个更原始的异常查静态块里干了什么、依赖的类是否完整。5.2 依赖重复与NoSuchMethodError类加载冲突的常见面孔除了上面两个报错类加载冲突还经常以 NoSuchMethodError、LinkageError 的面孔出现。这通常和依赖重复有关同一个类出现在多个 Jar 里或者一个 Jar 的不同版本被打进最终的 classpath。编译时你对着的是新版本的类运行时有另一个类加载器先加载了旧版本旧版本里没有某个方法运行到调用处就抛 NoSuchMethodError。我曾经排查过一个服务里 NoSuchMethodError 的问题。调用方引用的库方法签名是对的但还是报错最后用工具打印出实际加载到的类文件头部才确认class 文件是最旧的版本。问题是某个聚合依赖把旧版本传递进来了而它又恰好在 classpath 中被优先找到。解决方向就两个用依赖管理工具的统一版本机制把版本对齐或者在最终打 Jar 时显式排除掉不需要的旧版本保证生产环境 classpath 里每个类只有一份。排查这个家族问题的通用思路是先确认代码里调用的方法/字段真的存在于运行时加载到的那个类里。这两个对象很可能不是同一个。你要顺着谁加载了它、从哪个来源加载的去查而不是被报错信息里的类名唬住。5.3 一次线上报错的完整排查链路分享一次印象比较深的排查。某个查询接口在压测时突然开始报 NoClassDefFoundError但应用刚启动时运行得好好的。我当时的排查顺序是先看异常堆栈的 Caused by 部分发现根因是一个第三方工具类的静态块里连不上某个外部服务初始化抛了异常。再往回看为什么以前没触发因为那个工具类之前没有被任意请求路径触达属于延迟加载等到压测第一次走到这段路径时才触发初始化。于是修复方向就清晰了——不是依赖缺失而是静态初始化依赖的资源不可靠。调整方式是把那个工具类的初始化时机提前到启动阶段并且加上降级保护避免运行期突然初始化失败。这条链路里最有价值的一步是别把 NoClassDefFoundError 当成品名问题第一时间往 Caused by 链里挖。类加载异常经常只是一个表象真正的病灶藏在静态块初始化失败、方法区空间不足、依赖版本错位这些地方。另外可以多用启动参数-verbose:class或者 jcmd 加 Java 自带诊断工具直接看某个类到底是从哪个 Jar、被哪个加载器加载的这比对着报错猜效率高得多。6. 线程上下文类加载器双亲委派体系里的反向通道6.1 SPI场景下的委派失灵与破解思路双亲委派模型看似完美但在 SPI服务提供者接口场景下会卡住。以 JDBC 为例java.sql 包下的 DriverManager 是 JDK 核心类库按双亲委派它由启动类加载器加载而具体数据库驱动的实现则躺在应用 classpath 里由应用类加载器加载。当 DriverManager 内部想通过 Class.forName 加载驱动类时请求顺着启动类加载器向上走可启动类加载器根本看不到应用 classpath结果就是找不到类驱动永远无法加载。Java 设计者给出的解决方案是线程上下文类加载器。每个线程可以设置一个 contextClassLoader核心类库在需要跨加载器加载外部实现时会主动使用当前线程的 contextClassLoader 来加载相当于显式留了一条反方向的通道。DriverManager 就通过Thread.currentThread().getContextClassLoader()来加载具体的驱动类。这样既保留了核心类只加载一份的隔离性又让核心代码有能力触达应用侧的实现。理解了这个设计就不难理解为什么很多中间件里都有SPI 加载器的说法它们本质上都是利用线程上下文类加载器去突破双亲委派的边界把由谁加载的控制权交给部署方。6.2 线程上下文类加载器的使用姿势与风险日常写代码时你很少需要主动碰线程上下文类加载器但框架层经常用。如果你确实要用基本姿势是ClassLoader contextCL Thread.currentThread().getContextClassLoader(); try { Class? clazz Class.forName(某个SPI实现类, true, contextCL); // 通过 clazz 反射构造实例 } finally { // 如果临时替换过上下文加载器务必还原 }这里有一个非常容易忽略的风险线程上下文类加载器是线程级的全局状态。如果你在某段代码里临时把当前线程的 contextClassLoader 换成别的加载器而忘记在 finally 里恢复轻则导致后续业务代码用它加载出完全不同的类版本重则引发一系列诡异的类冲突。我看到过线上事故就是这么来的一个第三方组件在异步线程里修改了上下文加载器随后业务代码按新加载器加载了一堆类类身份全部错乱。另一个常见问题是线程池场景下 contextClassLoader 的传递。默认新建线程会继承父线程的上下文类加载器但线程池里的线程是复用的如果业务代码不主动在任务提交时把 contextClassLoader 传递到任务上下文那么池中线程的上下文加载器可能停在一个过期的版本上导致后续的 SPI 加载行为不符合预期。很多讲究的框架都会在提交任务时显式保存并恢复上下文类加载器原因就在这。最后想给一个具体建议如果你在排查类加载问题时发现某些类是被莫名其妙的加载器加载的第一反应就去看当前线程的 contextClassLoader 有没有被临时改过。这个字段看不见摸不着却是很多跨加载器 bug 的源头。打印日志时带上一行 currentThread 的 getContextClassLoader 和调用处的 getClassLoader往往能一眼定位问题。我做类加载相关的项目从第一次踩 ClassCastException 的坑到现在最大的感受是这个机制的设计其实非常自洽双亲委派保证核心类和业务类不互相污染线程上下文类加载器又给跨加载器协作留了口子自定义类加载器则把加载变成了可编程的环节。遇到类加载问题别慌先确认三层身份——字节码来源、加载器是谁、初始化状态是否正常大部分问题都能在十分钟内定位。如果环境允许平时多看一眼类加载日志、保持依赖版本干净比临时抱佛脚查报错要省心得多。