lloydsheng1. 一次ClassCastException引发的"代码没问题"迷案
1.1 报错场景：同一个接口，两个不同版本
先从我前段时间处理的一个线上问题说起吧。
那天晚上十点多，监控平台突然弹出一批告警，某个订单服务的错误率在五分钟内从0.1%飙到了12%。我赶紧翻日志，发现大量异常指向同一行代码——一个消息消费者在反序列化之后做类型转换的地方。报错信息很简短，但让人非常摸不着头脑：
code复制java.lang.ClassCastException: class com.example.common.dto.OrderDTO cannot be cast to class com.example.common.dto.OrderDTO
如果你没见过这种报错，第一次看到大概率是懵的。左边一个OrderDTO转成右边一个OrderDTO，同一个类名，同一个包名，甚至反编译出来字节码都差不多，但JVM就是铁面无私地告诉你：这俩不是同一个类型。
当时我们的第一反应是："代码没问题啊，转换的类明明就是同一个。"于是review代码、对比分支、回滚版本，折腾了快两个小时，测试环境怎么都复现不了。最后查到根源，问题出在类加载机制上。
1.2 根因：同一个类被不同类加载器加载了两次
那天的根因说起来一句话就能讲完：两个模块各自引入了不同版本的基础依赖，在容器环境下，同一个OrderDTO被两个不同的类加载器各加载了一遍。
在JVM里判断两个对象是不是同一个类型，不只是看类的全限定名，还要看它们是否由同一个类加载器加载。全限定名相同、类加载器不同，那它们就是两个完全不同的类，相互之间强转必然抛ClassCastException。
具体到那次问题，消息队列的消费者在启动时加载了一套旧版依赖，而业务代码里使用的是另一个WebAppClassLoader加载的新版依赖。两边都从自己所在的应用里拿到了OrderDTO，但这两个类在JVM眼里一个是"OrderDTO@AppClassLoader"，一个是"OrderDTO@WebAppClassLoader"。
这种情况在本地用main方法跑是绝对复现不了的，因为你只有一个AppClassLoader，所有类都是它加载的，必然不会冲突。只有到了容器环境、微服务环境、各种中间件叠加的环境里，类加载器的数量变多了，才容易冒出这种诡异问题。
1.3 从这次排查里得到的三个教训
那次问题解决之后，我复盘了一下，有三个点值得每个写Java的人记住：
第一个，报错信息越像"代码没问题"，越要先怀疑类加载器。特别是ClassCastException出现"同一个类"的前后，十有八九是类加载器隔离导致的，而不是代码逻辑错误。别急着查业务代码，先看这个类在运行时是从哪来的。
第二个，测试环境复现不了，不代表线上没啥事。多模块、多加载器、多依赖版本的环境，和本地单ClassLoader的环境，运行时的类加载路径差别非常大。遇到测试环境稳定、线上才炸的类加载问题，优先怀疑依赖冲突和类加载器隔离。
第三个，也是在后面无数次排查里让我得益最多的一条——类加载机制不是面试八股，它是线上疑难杂症的"案发现场"。很多Java面试题把类加载机制考得很细，但真正参加工作之后，你会发现它对排查问题的作用远比背概念大。越是复杂的运行环境，越需要理解"类是怎么被加载进来的"这一整套流程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 类加载的三个阶段：加载、连接、初始化到底做了什么
2.1 加载阶段：从字节码到Class对象的第一步
类加载机制的第一阶段是加载（Loading），这是JVM把class文件中的字节码读入内存，并生成java.lang.Class对象的过程。
这一步做的事情，简单说就是：通过类的全限定名获取定义此类的二进制字节流，将字节流所代表的静态存储结构转化为方法区的运行时数据结构，然后在堆内存中生成一个代表这个类的java.lang.Class对象，作为访问方法区中各种数据结构的入口。
这里要展开说一个点：加载时获取二进制字节流的动作，是最容易被扩展的环节。我们平时写的普通Java类是从classpath中的jar包或目录读取的，但我们完全可以从网络、数据库、加密文件，甚至动态生成的字节码来获取这个二进制流。这正是后面讲"自定义类加载器"的基础。
具体的加载动作，是通过ClassLoader.loadClass()或者Class.forName()来触发的。这两种方式有个区别值得记住：loadClass()默认只做加载和连接，不会执行初始化；forName()默认会执行初始化。这个差异在某些场景下会直接决定你拿到的类是否"可用"。
2.2 连接阶段：验证、准备、解析三件事
连接（Linking）阶段是类加载过程中最容易被跳过但至关重要的环节，它由三个步骤组成：验证（Verification）、准备（Preparation）、解析（Resolution）。
验证的目的是保证加载进来的字节流不会危害JVM自身的安全。比如检查字节码的魔数是否是0xCAFEBABE、版本号是否在当前JVM支持的范围内、常量池中的类型引用是否合法、字节码指令是否符合规范等。这一步保证了即使字节流是伪造的，也不能让JVM做出越界访问、类型误导这类危险动作。
准备阶段是为类的静态变量分配内存并设置默认零值。注意，这里说的零值是类型默认值，比如static int count此时被置为0，static Object obj此时被置为null。真正赋值为代码里写的初始值，要到后面的初始化阶段才执行。
有一个经典的坑：把准备阶段和初始化阶段混为一谈。如果你在代码里写了static final int MAX = 100，这个常量在准备阶段就直接被赋成100了，因为final常量在编译期就会被写入常量池。但如果你写的是static int MAX = 100，准备阶段只给MAX一个0，初始化阶段才变成100。
解析阶段是将常量池内的符号引用替换为直接引用的过程。符号引用就是一个字面量描述，比如类名、方法名、字段名；直接引用就是可以真正定位到目标对象的指针、偏移量或者句柄。
需要留意的是，解析阶段并不一定在连接阶段就全部完成。JVM规范允许某些解析操作被推迟到程序第一次真正使用这个符号引用时才进行，这叫"延迟解析"。这也是为什么你在-XX:+TraceClassLoading日志里看到类被加载了，但某些方法第一次调用时才报NoSuchMethodError——因为方法在调用前可能还没被解析。
2.3 初始化阶段：静态变量和静态块的执行时机
初始化（Initialization）阶段是类加载过程的最后一步，这里才会真正执行Java代码——也就是静态变量赋值语句和静态代码块中的内容。JVM会收集所有这些静态赋值动作，组合成一个<clinit>()方法并执行。
初始化阶段有一个必须掌握的知识：什么时候会触发初始化。JVM规范规定，只有在以下六种情况发生"主动引用"时，类才会被初始化：
- 使用
new关键字实例化对象、读取或设置类的静态字段（非final常量）、调用类的静态方法； - 使用反射进行调用时；
- 初始化子类时，如果父类还没初始化，先触发父类的初始化；
- JVM启动时，初始化包含
main方法的主类； - 使用JDK 7起加入的动态语言支持时，若某个
java.lang.invoke.MethodHandle实例最终解析的结果是类的静态方法句柄； - 接口中定义了
default方法时，如果接口的实现类被初始化，该接口会在实现类初始化之前被初始化。
反过来，被动引用不会触发初始化。比如通过子类引用父类的静态字段，只会触发父类的初始化，不会触发子类的初始化；通过数组定义来引用类，也不会触发该类的初始化；引用常量池中的final常量，同样不会触发初始化。
这个知识在实际开发中容易被忽视。我见过有同事在静态代码块里做耗时操作，结果系统启动时只是扫描了一些类定义，静态块没执行，导致某些初始化逻辑延迟到了真正使用类的时刻才触发，直接拖垮了第一个请求。
2.4 最容易误导新手的几个时间点
说到类加载机制里的"时间点"，有几个细节非常容易踩坑。
第一个，类的加载时机并没有JVM规范强制规定。也就是说，JVM可以在启动时就把所有类都加载进来，也可以延迟到类第一次被主动引用时才加载。HotSpot虚拟机的策略倾向于延迟加载，很多类直到被真正使用的那一瞬间才被加载和连接。所以你在-XX:+TraceClassLoading里看到的大量类加载日志，并不代表这些类是启动时加载的。
第二个，加载阶段和初始化阶段之间可能有很长的时间间隔。一个类可以被加载并连接，但没有被初始化，可以存放很久。这也是模板方法设计模式在JVM层面的一个体现：加载和连接是"准备"，初始化是"真正开始用"。
第三个，Class对象和实例对象是两个不同维度的东西。String.class是JVM创建的Class对象，它代表String这个类型本身；而new String("hello")是String类型的一个实例。类加载机制处理的是前者，实例化处理的是后者。搞清楚这两个概念，后面理解反射、动态代理、泛型擦除都会顺很多。
3. 双亲委派模型：三个内置类加载器怎么分工
3.1 三个内置类加载器：Bootstrap、Platform、Application
JVM自带了三个内置的类加载器，从高到低依次是：
- 启动类加载器（Bootstrap ClassLoader）：负责加载JVM自身运行所需的核心类，比如
java.*、javax.*等JDK基础库。它不是Java类，而是由C++实现，在Java代码中引用它时会得到null。这就是为什么你在IDEA里执行打印String.class.getClassLoader()，输出结果是null而不是一个类加载器对象。 - 平台类加载器（Platform ClassLoader）：JDK 9之前叫扩展类加载器（Extension ClassLoader），负责加载JDK扩展目录中的类。JDK 9模块化之后改名，职责变成加载一些平台相关的模块。
- 应用程序类加载器（Application ClassLoader）：也叫系统类加载器，负责加载classpath（也就是
-classpath或-cp指定的路径）下我们写的业务类和第三方类库。我们平时写的代码绝大多数都是它加载的。
这三个加载器的层级关系是：Application的父加载器是Platform，Platform的父加载器是Bootstrap。这里的"父"不是继承关系，而是组合关系——每个加载器内部保存了一个parent字段指向它的双亲。
3.2 一个Java文件，两行代码，看清类加载器
讲再多理论，不如自己敲两行代码看结果。假设你有一个最简单的类：
java复制public class ClassLoaderDemo {
public static void main(String[] args) {
// 核心类由Bootstrap ClassLoader加载，返回null
System.out.println("String: " + String.class.getClassLoader());
// 我们自己写的类由Application ClassLoader加载
System.out.println("ClassLoaderDemo: " + ClassLoaderDemo.class.getClassLoader());
}
}
运行结果基本是这样的：
code复制String: null
ClassLoaderDemo: jdk.internal.loader.ClassLoaders$AppClassLoader@xxxx
这个结果直观地展示了两个事实：核心库由Bootstrap加载，所以getClassLoader()返回null；业务代码由AppClassLoader加载。这是理解类加载器的第一个实操验证。
3.3 双亲委派的完整流程与设计原因
双亲委派模型的完整流程可以这样描述：
当一个类加载器收到类加载请求时，它不会尝试自己去加载这个类，而是把请求委派给父类加载器。每一层都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中。只有当父类加载器反馈自己无法完成这个加载请求（在它的搜索范围内找不到这个类）时，子加载器才会尝试自己去加载。
这个设计的核心原因有两个。
第一个是安全性。假设没有双亲委派，每个类加载器都自己加载，那么你完全可以写一个包名叫java.lang、类名叫String的类放到classpath里，应用加载器会把它加载进JVM，替换掉核心API。有了双亲委派，所有java.*的加载请求都会先交给Bootstrap ClassLoader，它只会加载JVM自带的类，你写的冒牌货永远不会被加载。这是Java保证类型安全的一道关键防线。
第二个是避免重复加载。同一个类被不同的类加载器加载后，JVM会认为它们是不同的类，会引发各种兼容性问题。通过双亲委派，同一个类在整个JVM里尽量只被同一个加载器加载一次，减少冲突的可能性。
3.4 JDK 9前后的变化：Extension变成Platform
这里必须要提JDK 9模块化（JPMS）带来的变化，因为很多老文章还在使用旧称呼，会导致新手在排错时对不上号。
JDK 9之前，结构是Bootstrap -> Extension -> Application。JDK 9之后，Extension ClassLoader被更名为Platform ClassLoader，并且不再从lib/ext目录加载扩展包，改为加载平台模块。同时对java.*的加载做了更细粒度的模块控制。
这个变化对你的实际影响主要有两点：一是看到类加载器名称里出现PlatformClassLoader不要再觉得陌生；二是当你用Class.forName()加载一个较老的扩展类时，可能面临模块不可见的错误。如果你在升级JDK版本后遇到类找不到，但jar包明明在，先看看是不是模块可见性导致的。
还有一个更隐蔽的变化：JDK 9之后，类加载器的委派关系不再是一棵严格的树，因为模块化的模块依赖关系可以跨加载器存在。比如Platform ClassLoader可能委托给Application ClassLoader去加载某些服务提供者类，这在老版本里是不可能发生的。如果你深入研究，会发现这是一个"双向"的委派。记住这个大方向即可，写代码时对"双亲委派一定成立"这个假设要保持警惕。
4. 打破双亲委派的实战场景：SPI、Tomcat、JDK模块化
4.1 JDBC的DriverManager：为什么SPI必须用线程上下文类加载器
双亲委派模型虽然好，但在某些场景下会显得"死板"，最典型的就是JDK的SPI（Service Provider Interface）机制。
以JDBC为例：java.sql.DriverManager位于java.sql包，由Bootstrap ClassLoader加载。但JDBC的具体驱动实现，比如MySQL的com.mysql.cj.jdbc.Driver，是第三方jar包，由Application ClassLoader加载。
问题来了：DriverManager是引导类加载器加载的，按双亲委派规则，它只能看到Bootstrap以及其"子孙"加载器加载的类。当它想通过Class.forName()加载MySQL驱动时，传给它的类加载器是DriverManager自己的类加载器，也就是Bootstrap，自然找不到com.mysql.cj.jdbc.Driver。
解决思路也很直接：不按双亲委派走，让DriverManager通过一个"旁路"去拿到业务代码的类加载器。这个旁路就是线程上下文类加载器（Thread Context ClassLoader，简称TCCL）。JVM允许每个线程保存一个contextClassLoader，默认是Application ClassLoader。DriverManager会从当前线程的上下文类加载器去加载驱动实现，从而绕开了双亲委派的搜索路径限制。
这背后的通用模式就是：父加载器加载的代码，需要调用子加载器才能加载的实现类时，必须通过线程上下文类加载器来做逆向的类加载。
在实际开发中，这类问题也常见于自研框架。比如你写了一个基础组件包放在Bootstrap或者Spring的父加载器里，它需要动态加载业务方的实现类，你就得复刻这个思路，显式获取业务方所在的类加载器，然后委托它去加载。
4.2 Tomcat的反向委派：让每个Web应用拥有独立类加载器
Tomcat的设计是打破双亲委派的又一个典型。
Tomcat要同时部署多个Web应用，每个应用可能有自己的WEB-INF/classes和WEB-INF/lib。而且不同应用完全有可能使用同一个第三方库的不同版本。如果所有应用都由同一个Application ClassLoader来加载，那版本冲突就是必然的。
Tomcat的解法是给每个Web应用都建一个独立类加载器，叫WebAppClassLoader，同时让它的加载顺序反着来：每个Web应用类加载器会优先加载自己WEB-INF/classes和WEB-INF/lib下的类，找不到时才委派给父加载器。
为什么必须反过来？因为如果按标准双亲委派先找父加载器，那么两个应用引用的同名同包但不同版本的jar包，只会按"先到先得"被加载一次，后加载的应用只能被迫使用先加载那个版本。这显然无法满足隔离需求。
所以Tomcat的加载顺序大致是：WebAppClassLoader先尝试自己加载，找不到时才委派给父加载器（此时父加载器自己的加载流程仍然是双亲委派式）。这种机制保证了应用之间的类隔离，但也意味着同一个公共类在不同应用里可能被不同的WebAppClassLoader各加载一遍，这正是文章开头那个线上ClassCastException的温床。
理解了Tomcat的机制，以后再遇到"同一个类在不同Web应用里行为不一致"的问题，你就知道该往哪个方向排查了。
4.3 JDK 9模块化之后：类加载器不再是严格的树
我一直觉得，JDK 9模块化之后，如果你还用"严格的树状双亲委派"来理解类加载器，会在某些场景下出错。
模块化系统引入了一个叫"模块层"（Layer）的概念。每个模块显式声明自己依赖哪些模块，JVM会根据依赖关系来决定模块间如何互相访问。由于模块依赖图不一定是"自上而下"的单向树，类加载器的委派关系也可能不再是纯粹的"自底向上"。
举个最简单的例子：java.sql模块由Platform ClassLoader加载，但它依赖的JDBC驱动实现是在Application ClassLoader层的模块里提供的。模块系统允许Platform ClassLoader在加载JDBC驱动时，委派给Application ClassLoader去加载——这在旧版严格双亲委派下是不可想象的。
这个变化对开发者的实际影响是：不要再用"绝对不可能"来形容类加载器的加载来源。在模块化环境下，同一个类被哪个加载器加载，可能取决于模块依赖关系，而不是简单的层级关系。遇到"这个类明明在classpath里，但加载它的ClassLoader不是我想的那个"这种问题时，先考虑模块化带来的委派反转。
5. 类加载问题排查链路：三个报错的完整定位过程
5.1 ClassNotFoundException和NoClassDefFoundError：一字之差排查方向完全不同
这是Java面试里非常高频率的对比，也是实际工作中高频出现的报错。但真正把它们区分清楚的人，说实话不多。
先看定义。
ClassNotFoundException是java.lang.Exception的子类，属于受检异常。它表示在代码中显式地尝试通过类名加载类时，在给定的类路径中找不到对应的类。典型场景是：
- 调用
Class.forName("com.example.Foo")时，classpath里没有这个类； - 调用
ClassLoader.loadClass("com.example.Foo")时找不到； - 配置文件中写了类名，框架通过反射加载时找不到。
这种报错通常发生在编译通过、运行期类路径缺失，或者类名拼写错误（包括包名错误）、依赖版本不对等情况下。
NoClassDefFoundError是java.lang.Error的子类，属于致命错误。它的含义不是"找不到类文件"，而是"这个类在编译和加载时存在，但运行时发现它没法被正确初始化或者无法被链接"。典型场景是：
- 类的静态初始化块抛了异常，类初始化失败；
- 这个类依赖的另一个类在运行时缺失；
- 类的加载因为某种原因中断，留下了"半成品"的残缺状态。
举例说明：你有一个类A，它的静态代码块里new了一个类B。B不在classpath里。当JVM尝试加载并初始化A时，发现B缺失，于是A的初始化失败。后续任何地方再引用A，就会直接抛出NoClassDefFoundError，而不是ClassNotFoundException。
这两者的排查方向差别很大。看到ClassNotFoundException，第一件事是检查classpath、jar包依赖、类名全限定名；看到NoClassDefFoundError，第一件事是检查这个类依赖了哪些其他类、静态初始化里有没有异常。
5.2 ClassCastException：先查类加载器归属
如前文所说，ClassCastException在"明明是一个类却被强转失败"时，极大概率是类加载器隔离问题。排查这类问题，最关键的是确认这个类到底是由哪个类加载器加载的。
在Spring Boot的FatJar环境下，类加载器是LaunchedURLClassLoader；在Tomcat环境下，是WebAppClassLoader；在OSGi环境下，可能还会更复杂。在排查时，你可以在代码里临时输出一下：
java复制System.out.println(obj.getClass().getClassLoader());
System.out.println(targetClass.getClassLoader());
如果输出结果中的类加载器对象不是同一个，比如一个是LaunchedURLClassLoader、一个是AppClassLoader，那就可以确定是类加载器隔离导致的类型不一致了。
但有些时候，你没法方便地在报错位置加日志。这时候需要借助Arthas这类在线诊断工具，在下一节详细讲。
5.3 用Arthas快速定位"这个类是谁加载的"
Arthas是阿里巴巴开源的Java诊断工具，对排查类加载问题非常有用。我用的比较多的命令有这几个：
sc -d 全限定类名：查看类信息，输出里包含classLoaderHash字段，就是这个类对应的类加载器的哈希值。classloader -t：以树形结构展示当前JVM中所有类加载器及其父子关系。classloader -c <classLoaderHash>：查看某个具体类加载器加载了哪些类。jad 全限定类名：反编译指定类，可以确认这个类是不是你要的那个版本（类代码和预期是否一致）。
有一次排查线上问题，我用sc -d com.example.common.dto.OrderDTO发现两个类加载器的hash不同，再配合classloader -t看树形结构，一眼就确定了一个由AppClassLoader加载，另一个由WebAppClassLoader加载。接着用jad分别反编译，还发现两个版本的方法体竟然有差异，这就实锤了依赖版本冲突的问题。
整套排查思路总结下来就是：先确定报错的类是谁加载的，再对比加载器之间的层级关系，最后检查各自加载的类内容是否一致。顺序不要搞反，否则容易绕进业务代码的细节里出不来。
5.4 一个完整案例：多环境依赖冲突的排查复盘
再把实战链路串起来看一个综合案例，这是一个比较典型的"依赖冲突+类加载器隔离"组合问题。
场景是这样的：A服务在本地和测试环境都稳定运行，一上生产环境，频繁出现NoSuchMethodError，偶尔出现ClassCastException。报错类指向第三方工具库com.fasterxml.jackson.databind.ObjectMapper。
排查第一个动作，我先看报错日志里的完整栈信息。NoSuchMethodError通常说明编译时用的方法和运行时加载的方法签名不一致，基本可以锁定到依赖版本冲突。
第二个动作，用mvn dependency:tree查看依赖树，发现项目里确实同时引入了Jackson 2.12和2.15两个版本。Maven仲裁一般会选路径更短的版本，但另一个框架内部传递依赖又强制改了版本，导致classpath里混入了两个版本的类。
第三个动作，到Java进程里用Arthas确认运行时实际加载的是哪个版本。用sc -d com.fasterxml.jackson.databind.ObjectMapper看了加载器，再配合jad反编译确认方法签名，发现实际加载的版本和编译时不一致。
修复方式要根据具体场景选择：统一依赖版本、排除传递依赖、使用依赖管理BOM、或者给不同模块配置不同的类加载器隔离规则。当时我们的方案是统一版本并在父POM里用dependencyManagement锁定，同时排查了是否有框架强依赖老版本，最终通过exclusion排除解决。
这个案例里有两点值得强调：一是不要一看到NoSuchMethodError就panic，先看是编译期不一致还是加载器隔离问题；二是Maven仲裁的结果只是"classpath上冲突时的默认选择"，不一定代表运行时真实加载的类，还是要以JVM内实际为准。
6. 手写一个加密Class的自定义类加载器
6.1 什么场景需要自定义类加载器
自定义类加载器不是面试题里的花架子，它在真实场景里有非常实际的作用。
最典型的场景就是代码加密保护。class文件以字节码形式存在，用JD-GUI这类反编译工具可以直接看到近乎源码级别的内容。如果你希望核心业务代码不被轻易反编译，可以在打包时对class文件做一层加密，然后在运行时通过自定义类加载器解密。这样磁盘上的class文件是密文，JD-GUI打开就是乱码，但JVM运行完全不受影响。
其次是从非标准位置加载类。比如类不在classpath里，而是存放在数据库BLOB字段、远程服务器文件系统、甚至内存缓存中，这时候就需要自定义类加载器从这些来源读取字节流。
再次是类隔离和热部署。框架型产品为了隔离不同插件，或者为了实现运行时代码热替换，也需要自定义类加载器。Tomcat、OSGi、Spring Boot DevTools内部的实现都离不开这一套机制。
6.2 从class文件加密到加载：完整代码
我以一个可运行的完整案例来讲。假设我们要加密com.example.SecretUtil这个类的class文件，然后在运行时用自定义类加载器加载它。
第一步，写一个加密工具，用简单的XOR运算处理字节码：
java复制import java.io.*;
import java.nio.file.*;
public class ClassEncryptor {
// XOR密钥
private static final byte[] KEY = "my-secret-key-2024".getBytes();
public static byte[] encrypt(byte[] data) {
byte[] result = new byte[data.length];
for (int i = 0; i < data.length; i++) {
result[i] = (byte) (data[i] ^ KEY[i % KEY.length]);
}
return result;
}
public static void main(String[] args) throws Exception {
// 读取编译后的class文件
Path classFile = Paths.get("target/classes/com/example/SecretUtil.class");
byte[] original = Files.readAllBytes(classFile);
// 加密并写入新的位置
byte[] encrypted = encrypt(original);
Files.write(Paths.get("target/encrypted/com/example/SecretUtil.class"), encrypted);
System.out.println("encrypted class size: " + encrypted.length);
}
}
第二步，写一个自定义类加载器，继承ClassLoader，重写findClass方法，按包名去找加密文件并解密：
java复制import java.io.*;
import java.nio.file.*;
public class EncryptedClassLoader extends ClassLoader {
private static final byte[] KEY = "my-secret-key-2024".getBytes();
private final Path encryptedRoot;
public EncryptedClassLoader(Path encryptedRoot, ClassLoader parent) {
super(parent);
this.encryptedRoot = encryptedRoot;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
// 将全限定名转为文件路径
String path = name.replace('.', '/') + ".class";
Path encryptedFile = encryptedRoot.resolve(path);
// 读取加密内容并解密
byte[] encryptedBytes = Files.readAllBytes(encryptedFile);
byte[] decryptedBytes = new byte[encryptedBytes.length];
for (int i = 0; i < encryptedBytes.length; i++) {
decryptedBytes[i] = (byte) (encryptedBytes[i] ^ KEY[i % KEY.length]);
}
// 调用defineClass把字节数组转为Class对象
return defineClass(name, decryptedBytes, 0, decryptedBytes.length);
} catch (IOException e) {
throw new ClassNotFoundException(name, e);
}
}
}
第三步，使用这个加载器：
java复制import java.nio.file.*;
public class Main {
public static void main(String[] args) throws Exception {
Path encryptedRoot = Paths.get("target/encrypted");
EncryptedClassLoader loader = new EncryptedClassLoader(encryptedRoot, ClassLoader.getSystemClassLoader());
Class<?> clazz = loader.loadClass("com.example.SecretUtil");
Object instance = clazz.getDeclaredConstructor().newInstance();
// 通过反射调用方法
System.out.println(clazz.getMethod("getSecret").invoke(instance));
}
}
注意一个前提：SecretUtil类本身不能写在classpath里，否则会被双亲委派里的Application类加载器抢先加载。要想让自定义加载器真正干活，要么把原始class文件从classpath中移除，要么打破双亲委派。
6.3 findClass和loadClass：保留双亲委派和打破双亲委派的关键
很多新手写自定义类加载器时，搞不清到底该重写findClass还是loadClass。这里说一下关键区别。
ClassLoader的loadClass方法实现了双亲委派逻辑：先调用findLoadedClass检查当前加载器是否已加载过这个类，没有则委派给父加载器，父加载器也不行时才调用自己的findClass。
而findClass只是一个"空壳子"，默认实现直接抛ClassNotFoundException。它的定位是：留给子类去实现"从哪里获取字节码"。
所以在自定义类加载器时，如果你希望保留双亲委派模型（推荐，大多数场景都该保留），重写findClass就足够了。父加载器能加载的类还是会由父加载器加载，只有父加载器加载不到时，才会走你写的findClass逻辑。
如果你希望打破双亲委派，比如强制让这个类只能由你的加载器加载，那才需要重写loadClass，并且在自己的逻辑里不要调用super.loadClass。Tomcat的WebAppClassLoader就是这么干的。
这里有一个常见问题：你自己写的加载器加载一个没有在classpath里出现的类时，如果这个类又引用了别的类，这些被引用的类会由谁加载？ 答案是由这个类自己的加载器去加载。如果被引用的类也在加密目录里，那么同样会被你的findClass找到；如果被引用的类是JDK库或者classpath里的类，则会走双亲委派，由父加载器加载。这种"类加载器会带着它所加载的类的依赖继续解析"的概念，是理解模块隔离和依赖冲突的基础。
6.4 defineClass之后，需要主动resolveClass吗
在findClass方法里，最后一个关键调用是defineClass。这个方法把字节数组解析成JVM认可的Class对象。很多教程在defineClass之后还会加一行resolveClass(clazz)。
resolveClass是干什么的？它对应前面讲的连接阶段中的解析步骤。JVM允许解析被延迟到类真正使用时才进行。也就是说，defineClass返回的Class对象已经可以被正常使用了，你调用newInstance、反射调用方法、访问字段都会自动触发链接。真正需要主动调用resolveClass的场景非常少，比如你希望在类"准备好"的第一时间就完成所有链接动作，避免后续首次使用时的延迟。
从实践角度看，我通常不在自定义类加载器里调用resolveClass，因为JVM的按需解析机制在绝大多数场景下更高效，能减少不必要的解析开销。很多在线教程代码里都保留这行，也不会出错，但如果你理解不了它的作用，就不用刻意加。
还有一个细节：defineClass可以指定类的保护域（ProtectionDomain），如果不指定，默认使用加载器的getPackage相关逻辑来推断。在加密类加载场景中，由于类的字节被解密后才传给defineClass，而且类的包名（Package）可能需要手动定义，否则涉及的getPackage()判断可能返回null。如果遇到包相关异常，可以看一下是否需要主动definePackage。
7. 类加载与Metaspace OOM：动态类过多的排查思路
7.1 你以为是堆内存不够，其实是Metaspace
先澄清一个比较容易混淆的概念。热词里有个java: outofmemoryerror: insufficient memory，这是JVM进程在启动时无法从操作系统分配到足够内存时的报错，属于native内存分配失败，跟堆内存和类加载没有直接关系。而Metaspace OOM的报错是java.lang.OutOfMemoryError: Metaspace，两者是不同的问题，排查思路也完全不同。
Metaspace（元空间）是从JDK 8开始替代永久代（PermGen）的方法区实现，主要用于存放类的元数据信息，比如类的结构、方法信息、字段信息、常量池等。这些数据是类加载过程中产生的，一个类被加载后，它的元数据就占一块Metaspace空间。
Metaspace的大小默认受系统物理内存限制，可以动态扩展。如果程序在运行过程中不断产生新的类，且这些类不可被卸载，Metaspace的占用就会持续上涨，最终触发OOM。这种OOM和堆OOM的表现有区别：堆OOM通常是对象太多无法回收，Metaspace OOM是类的数量本身膨胀到了内存装不下的地步。
7.2 哪些操作会疯狂产生Class对象：热部署、动态代理、脚本引擎
我整理了一下实际工作中最容易导致Metaspace膨胀的操作，按出现频率排个序：
第一是热部署/热加载。每次重新部署应用，JVM通常会创建新的类加载器来加载新的类版本，如果旧类加载器及其加载的Class对象没有被回收，就会持续堆积。在开发阶段使用DevTools、JRebel这类工具时，如果你频繁重启应用上下文，也会看到Metaspace占用快速上升。
第二是动态代理和CGLib增强。CGLib在运行时为每个目标类生成一个子类，这些子类的Class对象会被加载到Metaspace中。Spring AOP默认使用CGLib，如果你的项目用AOP给大量方法做了增强，每个被代理的类都会产生新的Class。如果代理类数量庞大、反复创建新的代理，Metaspace也会上涨。
第三是脚本引擎和表达式求值。比如在JVM里跑Groovy、JavaScript（Nashorn）、或者频繁用SpEL表达式，每次执行都可能动态生成新的类。这类场景对Metaspace的消耗比静态代码要大得多。
第四是大量使用反射动态加载不同Class。比如一些框架按照配置去加载各种策略类、插件类，如果加载的类数量极其庞大且不常复用，也会增加Metaspace压力。
7.3 排查与参数建议：MaxMetaspaceSize、TraceClassLoading、jstat
面对Metaspace OOM，我建议按下面这个顺序排查。
第一步，确认报错信息。日志里出现OutOfMemoryError: Metaspace，或者看到GC overhead limit exceeded但同时Metaspace占用很高，先认定为Metaspace问题。
第二步，观察Metaspace的占用变化。用jstat -gc <pid>可以看到M区（Metaspace）的容量和使用量。如果M列的值持续上涨、FGC频繁触发，基本可以锁定是类元数据泄漏。
第三步，开启类加载日志，看哪些类在被反复加载：
code复制-XX:+TraceClassLoading -XX:+TraceClassUnloading
日志里会出现大量重复的类名。比如同一个com.example.MyClass被加载了上百次，说明有类加载器泄漏。
第四步，用Arthas的classloader命令查看当前JVM里所有类加载器的数量。如果你发现类加载器数量爆炸（比如几百上千个WebAppClassLoader），那就是典型的"每次部署都new了一个加载器，旧的没有被回收"。
第五步，针对具体场景修复。热部署场景要确认旧类加载器为什么没有被回收（通常是因为被ThreadLocal、静态变量、JNDI上下文等持有了引用）；动态代理场景要考虑减少代理类的生成、用JDK动态代理替代CGLib；脚本引擎场景要评估缓存编译结果，避免重复编译生成新类。
JVM参数上，生产环境建议显式设置Metaspace上限，避免无脑膨胀把整台机器内存耗尽：
code复制-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
MetaspaceSize是初始水位线，MaxMetaspaceSize是硬上限。设置上限后，系统在接近上限时会更积极地进行类卸载，但同时也会增加Full GC频率，需要根据实际压测结果调整。
7.4 日常开发中避免Metaspace OOM的实操习惯
根据我个人踩坑经验，有几个习惯能显著降低Metaspace OOM的概率。
第一个习惯：上线前先压测验证类加载稳定性。特别是使用Spring Boot DevTools、热部署插件的团队，要确认生产环境没有开启这些热部署能力，否则每次发版都可能产生新的类加载器。
第二个习惯：对脚本引擎和表达式引擎做缓存，别在每次请求里新建。比如GroovyShell、SpelExpressionParser都是重量级对象，反复创建不仅性能差，还可能反复生成Class。正确做法是全局复用，或者对编译后的Script/Expression做缓存。
第三个习惯：留意全局静态集合被塞入ClassLoader引用。ClassLoader是典型的"看不见泄漏源"。如果一个静态Map里存了某个由自定义加载器加载的对象，这个静态Map就间接持有了该加载器，导致整个加载器及其加载的所有类都无法被回收。类加载器无法回收，Metaspace就只增不减。
第四个习惯：用Arthas做日常体检。不用等到OOM才慌，我每隔一段时间会对运行中的服务执行一次classloader和dashboard，看类加载器数量和Metaspace走势。发现异常就提前处理，成本比线上OOM低得多。
记得把这些参数加到你的JVM监控大盘里：Metaspace使用率、每次Full GC后Metaspace是否下降、类加载器数量变化曲线。这三条数据一旦异常，比等报错日志出现要早好几天。
回到文章开头那个线上ClassCastException，我现在遇到任何类相关的诡异报错，第一反应都是先查看类加载器归属，再去看业务逻辑。这个习惯帮我少走了很多弯路。类加载机制这张网，平时看不见摸不着，但一旦出问题，它就是把你从"代码绝对没问题"的错觉里拉出来的那根线。