JVM名称空间与内存模型：类加载器如何引发ClassCastException

我们接线上事故的时候，最怕的就是那种“看起来没问题，一上线就崩”的类冲突问题。有个项目，两个团队各自写了 User 类，包名也一样，代码合并时谁都没注意，结果联调阶段直接抛 ClassCastException，定位花了一整天。最后发现，两个 User 根本不是同一个类，一个被应用类加载器加载，另一个被某个框架的子加载器加载。这让我重新把“内存模型和名称空间”从头捋了一遍，尤其是名称空间这个老生常谈但经常被忽略的概念。

很多人一听到“名称空间”就想到 C++ 的 namespace 或者 Java 的 package，觉得只是个代码组织工具。但在 JVM 里，名称空间远不止这么简单，它直接决定了“同一个类名会不会被当成两个类”，还和元空间、类加载器、甚至 GC 的类卸载机制纠缠在一起。这篇文章我就从 JVM 视角把名称空间和内存模型的关系拆开讲清楚，顺便给一些能直接用到排查现场的思路。

1. 名称空间到底是什么：从源码隔离到运行时隔离

1.1 不同语言里的名称空间，解决的是同一个问题

名称空间的核心诉求是“隔离”。写代码时，两个文件里都叫 Utils 的类，如果没有隔离机制，编译器直接报重名。C++ 用 namespace，Java 用 package，Python 用 module，Go 用 package，名字不同，理念一致：给标识符加一个前缀空间，让同名不同源的东西可以共存。

但注意，源码层的隔离只是第一层。拿 Java 来说，package com.demo.a 和 package com.demo.b 可以各自定义 User，源码层面没问题，编译也没问题。运行时这些东西去哪了？答案是方法区，JDK8 以后叫元空间（Metaspace）。类的元数据、字段描述、方法字节码、常量池，都在元空间里躺着。

如果仅仅有 package，那 com.demo.a.User 和 com.demo.b.User 已经在类名上分开了，JVM 能区分它们。但是，如果两个不同类加载器都加载了 com.demo.a.User 呢？那 JVM 会把它俩当成完全不同的两个类，哪怕包名路径一模一样。这就是运行时名称空间的关键。

1.2 JVM 里的三层名称空间

要理解运行时隔离，得记住一个结论：JVM 中一个类的唯一标识是“类加载器 + 类的全限定名”，这是个二元组，不是类名本身。

第一层是源码名称空间，也就是 package，它决定编译期符号的唯一性。第二层是模块名称空间，JDK9 以后引入的模块系统（JPMS）在 package 之上再加了一层隔离，模块之间默认不互相读取。第三层是类加载器名称空间，每个类加载器拥有自己的命名空间，父加载器加载的类对子加载器可见，但两个兄弟类加载器之间互不可见。

举个实际例子：

bash复制# 有两个同名类文件
# com/demo/User.class
# 分别用两个 ClassLoader 实例加载
ClassLoader loaderA = new MyClassLoader("A");
ClassLoader loaderB = new MyClassLoader("B");
Class<?> classFromA = loaderA.loadClass("com.demo.User");
Class<?> classFromB = loaderB.loadClass("com.demo.User");
System.out.println(classFromA == classFromB); // false

两个 Class 对象不同，对应的 .class 文件可以完全一样，但 JVM 各自分配了独立的类元数据。这就是“名称空间”在内存层面的真实样子：相同的类名在不同类加载器里，是元空间里两份独立的类元数据。

1.3 类加载器的双亲委派与隔离边界

双亲委派模型规定，一个类加载器收到加载请求时，先委派给父加载器，父加载器找不到才自己加载。这保证了 Java 核心类库（java.lang.*）永远由引导类加载器加载，避免 core 类被篡改。

这个机制也划定了名称空间的边界。以 Tomcat 为例，每个 Web 应用有一个独立的 WebAppClassLoader，它们共享父加载器（System ClassLoader）加载的类，但彼此之间的类完全隔离。所以两个应用都可以依赖不同版本的 Spring，只要版本类名不同或者由各自加载器加载，就不会冲突。

这里有个关键点，JVM 对类的“可见性”是有方向的。子加载器能看到父加载器加载的类，所以 Web 应用能看到 Tomcat 核心类；但父加载器看不到子加载器加载的类，所以 Tomcat 核心代码不能直接引用 Web 应用里的类。这种单向可见性，就是一种严格的方向性名称空间。

注意：类加载器不是“树”而是“树形结构”，每个类加载器有且仅有一个父加载器，但可以有多个子加载器。双亲委派时，loadClass 方法会先检查父加载器有没有加载过，这一步本质是在父级名称空间查找已有类，避免重复加载。

2. 内存模型：JVM 怎么给这些“名称空间”分配地盘

2.1 JVM 内存区域的划分，类元数据住在哪

JVM 内存从线程角度看分两类：线程私有和线程共享。线程私有包括程序计数器、虚拟机栈、本地方法栈；线程共享包括堆、方法区（元空间）、直接内存。

堆是对象的主要栖息地，new 出来的对象实例都在这。栈上保存局部变量、方法调用帧、操作数栈。程序计数器记录当前线程执行到的字节码行号。直接内存是 DirectByteBuffer 所用的堆外内存，不受堆大小限制。

元空间（Metaspace）是 JDK8 取代永久代（PermGen）的产物，存储类元数据、方法字节码、常量池、注解信息。它最大的特点是使用本地内存，默认不设置上限，只要操作系统还有内存就能继续分配。这也意味着，如果类加载器泄漏，元空间会一路涨到系统 OOM。

2.2 Java 内存模型（JMM）与并发可见性

Java 内存模型和 JVM 内存区域是两个容易混淆的概念。JMM 描述的是线程通过主内存和各自工作内存交互的规则，定义了一组抽象的内存访问语义，用来保证并发下的可见性、有序性和原子性。

核心是 Happens-Before 规则。如果 A 操作 Happens-Before B 操作，那么 A 操作的结果对 B 操作可见。规则包括：程序顺序规则、监视器锁规则、volatile 变量规则、线程启动/中断/终止规则、传递性。

写一段演示代码：

java复制public class VisibilityDemo {
    private static boolean flag = false;
    private static int number = 0;

    public static void main(String[] args) throws InterruptedException {
        Thread writer = new Thread(() -> {
            number = 42;          // 操作1
            flag = true;          // 操作2
        });
        Thread reader = new Thread(() -> {
            while (!flag) {
                // 自旋等待
            }
            System.out.println(number); // 可能为 0，也可能为 42
        });
        writer.start();
        reader.start();
        writer.join();
        reader.join();
    }
}

flag 没有 volatile 修饰，reader 线程可能永远看不到 flag 的变化，number 的可见性也没有保证。这是 JMM 要解决的问题，和名称空间本身没有直接关系，但类的静态变量、类初始化时的内存屏障，都和 JMM 有关。

2.3 名称空间和内存模型是怎么挂上钩的

类加载器每次定义一个新类，都会在元空间写入一份类元数据。如果两个类加载器加载了同一个类名，元空间就会有两份独立的 Klass 结构。每个 Klass 有自己的常量池引用、静态变量、方法表。也就是说，名称空间的隔离直接造成了内存里元数据的多份拷贝。

这就带来一个实际问题：类加载器数量越多、每个加载器加载的类越多，元空间占用越大，GC 的类卸载压力也越大。 类卸载是 G1 等垃圾收集器在垃圾回收时的一个附带能力，它需要同时满足三个条件：类加载器不可达、该加载器加载的所有类都不可达、类对象不可达。换句话说，类加载器本身如果被泄漏了，它加载的类就永远无法卸载，元空间只会涨不会降。

从内存模型角度看，堆里的对象实例通过引用指向元空间的类元数据，对象头里有类型指针（_klass 指针），GC 遍历对象图时拿到这个指针找到 Class 对象和方法表。所以，“对象指向哪个类”完全由内存结构决定，运行时类型判断（instanceof、ClassCastException）用的就是这份类元数据的身份标识。

3. 实操：用代码还原名称空间隔离，并监控元空间和 GC

3.1 自定义类加载器，制造同名类冲突现场

理解名称空间不能只看文档，得跑一遍。下面这段代码自定义了一个简单类加载器，从磁盘读取 .class 字节并 defineClass。

java复制public class MyClassLoader extends ClassLoader {
    private final String name;
    private final String path;

    public MyClassLoader(String name, String path) {
        this.name = name;
        this.path = path;
    }

    @Override
    protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(className)) {
            Class<?> loadedClass = findLoadedClass(className);
            if (loadedClass == null) {
                if (className.startsWith("java.")) {
                    return super.loadClass(className, resolve);
                }
                try {
                    byte[] bytes = loadClassBytes(className);
                    if (bytes != null) {
                        loadedClass = defineClass(className, bytes, 0, bytes.length);
                    } else {
                        loadedClass = super.loadClass(className, resolve);
                    }
                } catch (Exception e) {
                    loadedClass = super.loadClass(className, resolve);
                }
            }
            if (resolve) {
                resolveClass(loadedClass);
            }
            return loadedClass;
        }
    }

    private byte[] loadClassBytes(String className) throws IOException {
        String fileName = path + "/" + className.replace('.', '/') + ".class";
        try (InputStream in = new FileInputStream(fileName)) {
            return in.readAllBytes();
        }
    }
}

这个加载器故意不走双亲委派（除了 java.*），保证每个实例都会重新加载类。然后加载两次同一个类：

java复制public class NamespaceDemo {
    public static void main(String[] args) throws Exception {
        String path = "/tmp/classes";
        MyClassLoader loaderA = new MyClassLoader("A", path);
        MyClassLoader loaderB = new MyClassLoader("B", path);

        Class<?> clazzA = loaderA.loadClass("com.demo.Payload");
        Class<?> clazzB = loaderB.loadClass("com.demo.Payload");

        System.out.println("loaderA class: " + clazzA.getClassLoader());
        System.out.println("loaderB class: " + clazzB.getClassLoader());
        System.out.println("same class object: " + (clazzA == clazzB));

        Object objA = clazzA.getDeclaredConstructor().newInstance();
        Object objB = clazzB.getDeclaredConstructor().newInstance();
        try {
            clazzA.cast(objB); // 必然会抛 ClassCastException
        } catch (ClassCastException e) {
            System.out.println("ClassCastException: " + e.getMessage());
        }
    }
}

输出结果是 same class object: false，最后一行必然抛异常。这就是类加载器名称空间隔离的直接表现：loaderA 和 loaderB 各自维护了一个 Map<类名, Class对象>，互不干扰。

实际开发中，这种情况经常出现在 OSGi、热部署插件、SPI 实现加载等场景。你看着日志里类名一模一样，但内存里根本不是一个类，强转必然炸。

3.2 用 jcmd 和 jstat 观察元空间与 G1 堆

光跑完代码，还得用工具验证内存变化。jcmd 和 jstat 是最常用的两个工具。

先看元空间使用量：

bash复制jcmd <pid> VM.metaspace

输出里会看到 Used、Capacity、Committed、Reserved 四组数据。Used 是实际使用的类元数据字节数，Reserved 是向操作系统申请的内存总量，Committed 是实际分配给 JVM 的内存块。类加载器越多、加载的类越多，Used 会增长。

如果要看类加载统计：

bash复制jcmd <pid> VM.classloader_stats

这个命令会列出每个类加载器的名称、存活和死亡的类数量、加载的字节数总和。如果发现某个加载器的类数量持续增长且不回收，基本可以断定类加载器泄漏。

看 GC 和堆概况：

bash复制jstat -gcutil <pid> 1000

输出列 M 代表元空间使用率，E 代表 Eden 区使用率，O 代表老年代使用率，G1CT 是 G1 并发标记周期结束后存活对象占比。如果 M 一直很高且不回落，就要考虑动态类生成或者类加载器泄漏。

G1 是 JDK9 以后默认的垃圾收集器，它把堆划分为很多 Region，物理上不分代，但逻辑上动态扮演 Eden、Survivor、Old 角色。由于名称空间的类元数据在元空间，而类的实例在堆的 Region 里，GC 时需要处理跨区域的引用关系。G1 通过 remembered set（RSet）记录 Region 之间的引用，从而在混合回收时能准确定位老年代到新生代的引用。

3.3 G1 如何回收“死类”：类卸载与元空间回收

元空间和堆虽然物理上分开，但回收是联动的。G1 在并发标记阶段找到不可达对象，如果某个类加载器和它加载的类都不可达，G1 就可以卸载类，元空间对应区域也会被回收。

但 G1 的类卸载是周期性的，不是每次 GC 都做。JDK11 以后，G1 在并发标记周期完成后会执行一次类卸载，默认开启。如果想观察类卸载情况，可以加参数：

bash复制-XX:+TraceClassLoading
-XX:+TraceClassUnloading

日志里会出现 [Unloading class com.demo.Payload] 之类的记录。没有类卸载日志，说明你的类加载器仍然被引用着，类无法卸载，元空间会持续增长。

实操心得：调试类加载器泄漏时，先用 jcmd <pid> VM.classloader_stats 看哪个加载器类数量突增，再用 -XX:+TraceClassLoading 复现一次现场，基本能快速圈定是谁把类加载器偷偷撑在手里没释放。

4. 常见问题与排查技巧实录

4.1 ClassCastException 与 LinkageError 速查表

我最常遇到的是第一种，表现是代码写了 if (user instanceof User)，结果返回 false，但日志里类名确实是 com.demo.User。新人第一次遇到会懵，实际上内存里有两个 User 类，分别由不同类加载器定义，instanceof 判断的是类对象身份，不是字符串名字。

4.2 Metaspace OOM 的常见解法

元空间 OOM 错误是 java.lang.OutOfMemoryError: Metaspace。原因基本是以下三者之一：动态生成类太多（比如大量 cglib 代理）、类加载器泄漏、-XX:MaxMetaspaceSize 设置过小。

解法按顺序来：

1. 确认是不是动态类生成导致。用 jcmd <pid> VM.metaspace 观察 Used 增长率，如果周期性暴涨，大概率是动态代理或反射调用在生成新类。
2. 检查类加载器是否泄漏。jcmd <pid> VM.classloader_stats 看是否有加载器类数量只增不减。
3. 临时调大上限，观察业务是否稳定：

   bash复制-XX:MaxMetaspaceSize=512m
   

   但这只是缓解，根本解法是找到谁在泄漏。

有个经典坑是 ThreadLocal 持有了类加载器引用，导致 Web 应用重启时类加载器无法被回收。Tomcat 重启几百次以后元空间就爆了。排查时用 jmap -histo:live <pid> 看 ThreadLocal$ThreadLocalMap 条数，如果异常膨胀，基本就能锁定。

4.3 类加载器泄漏的定位套路

我自己惯用的方式是三步走：

第一步，jcmd <pid> GC.class_histogram 找占用最多的类，确定大对象在哪。

第二步，jcmd <pid> VM.classloader_stats 看所有加载器的生存类数量。正常状态的加载器数量和类数量应该在长时间运行后保持平稳，如果某个加载器持续膨胀，就是泄漏源。

第三步，jmap -dump:live,format=b,file=heap.bin <pid> 抓 dump，用 MAT 打开，查找 java.lang.ClassLoader 的引用路径。重点看 GC Roots 到 ClassLoader 之间是否存在 ThreadLocal、静态集合、或者外部系统连接对象的引用链。

实操心得：不要一上来就抓大 dump，几百 MB 的文件分析起来很费劲。先用 jcmd 缩小排查范围，再决定要不要 dump。大多数情况下，VM.classloader_stats 输出已经能定位到具体是哪一类加载器在泄漏。

4.4 一次典型的名称空间冲突排查示例

有次线上服务 A 调用服务 B 的 SDK，SDK 内部把 com.sdk.entity.Result 加载到自定义类加载器里。应用代码通过接口拿到一个 Result 对象，想强转成 SDK 里声明的 Result，结果抛 ClassCastException。

排查日志发现，Result 在 SDK 的加载器里加载了一次，应用主加载器也加载了一次。为什么？因为 SDK 没有遵守双亲委派，强制用自定义加载器加载自身 jar 里的关键类。解决办法是去掉自定义加载逻辑，或者让 SDK 的加载器先把核心类委派给父加载器。有时只需要对特定包放弃双亲委派，比如：

java复制// 在 XML 或代码中配置
<loader-delegate>false</loader-delegate>

这个案例给我的教训是：类加载器的问题，不是靠改代码就能完美解决的，很多时候得从架构层面约定好“哪些包用谁的加载器”，否则就是无穷无尽的冲突。

最后讲一个小技巧。遇到莫名其妙的类冲突，先不要去看宏大的架构，用一条命令把类加载器关系打印出来，比啥都管用：

bash复制jcmd <pid> VM.class_hierarchy

这条命令会输出所有类加载器的父子关系和已加载的类摘要，能一眼看清楚你的类是从哪条加载路径进来的。我用了这么多年，每次排查类冲突问题都是先从这条命令开始。因为名称空间这件事，说到底就是“谁加载了它、它住进了哪块内存”的问题，把这两点搞明白，百分之八九十的类冲突都会找到答案。