前几天帮一个准备跳槽的朋友对面试题在“方法区到底存了什么”这个问题上卡了很久。他能背出“类的元数据、运行时常量池、静态变量”但当我追问“这个元数据在 HotSpot 里具体长什么样你代码里拿到的 Xxx.class 对象和方法区里那块东西是不是同一个”他就接不下去了。这不怪他网上关于方法区的答案大多停留在 JVM 规范层面没有落到 HotSpot 的具体实现上。实际在 HotSpot 中方法区里的类信息核心是一套叫 klass 的 C 对象树而 Java 层还有一个 java.lang.Class 对象作为它的“镜像”两者长得完全不像、位置也不一样却靠着一组指针互相绑定。这篇我把这层关系彻底拆开覆盖原理、类加载链路、工具验证和线上排查看完能真正回答这一系列高频 Java 面试题而不是只背结论。1. 方法区不是一块黑盒先看类信息是以什么形态落地的1.1 从 .class 文件到内存结构类加载做了什么我们写的 Java 代码被 javac 编译成 .class 字节码文件但 JVM 运行时不可能每次都去读磁盘上的文件它必须在内存里建一套“运行期版本”的类结构。这个转换动作就是类加载子系统干的活读取字节流、解析结构、校验合法性最后按照 HotSpot 内部定义的 C 对象布局在内存里生成一棵 klass 对象。注意这里的关键点.class 文件不是被原样搬运到内存的而是被“重组”了。字节码文件里的常量池、字段表、方法表会被拆散后填进 HotSpot 自己的数据结构里。方法的字节码会被挂在 Method 对象上常量池会被转换成 ConstantPool 对象字段信息会整理成字段表。这套运行期结构就是方法区中“类的元信息”这个说法背后的实体。如果你只从 JVM 规范的角度看方法区存放的是类信息、运行时常量池、静态变量但如果你从 HotSpot 源码的角度看所谓的“类信息”是一组具体的 C 对象。其中最核心的是 InstanceKlass它相当于一个类在虚拟机内部的“户籍档案”。后面我们会花一整章来讲它内部到底装了什么。1.2 永久代和元空间方法区在 HotSpot 中的两段历史HotSpot 对方法区的实现经历过一次大改JDK 7 及以前用“永久代PermGen”JDK 8 开始换成“元空间Metaspace”。永久代位于 Java 堆内受堆大小限制默认值又往往不大所以只要动态生成类稍微多一点就容易抛java.lang.OutOfMemoryError: PermGen space。类加载器的数量、反射和代理类的使用强度直接决定永久代的压力。JDK 8 移除永久代后类元数据改到本地内存native memory由 Metaspace 管理器统一分配。元空间不再占用堆内存默认也没有上限只受操作系统可用内存限制。这带来一个好处类的元数据和堆对象分离堆 GC 时不用再扫描整块类元数据区域但坏处也很明显如果你不限制 MaxMetaspaceSize元空间可能悄悄涨到把物理内存耗尽。对比项 永久代JDK7及以前 元空间JDK8 存储位置 Java堆内 本地内存不在堆 默认上限 MaxPermSize默认值偏小 MaxMetaspaceSize默认无上限 GC参与 Full GC会扫描永久代 元空间回收与堆GC联动但不在堆内 OOM错误信息 PermGen space Metaspace另外还有一个容易忽略的事实GC 日志里看到的 Metaspace 通常分两块——class space 和 non-class space。class space 是专门放 klass 元数据的连续区域默认约 1GBnon-class space 放常量池、方法元数据等。很多调优场景只看总的 Metaspace 使用量却没注意到 CompressedClassSpace 可能先触顶。1.3 方法区里的实际组成不只是 klass方法区在 HotSpot 里并不是一个单一的存储结构而是由多种对象共同构成的内存区域。大致包括这么几类类与接口的元数据InstanceKlass、ArrayKlass 等 klass 结构体运行时常量池ConstantPool 对象保存类的符号引用和字面量方法元数据与字节码Method、ConstMethod每个 Java 方法的字节码都挂在这里字段描述信息字段名、类型、修饰符、偏移量存在于 InstanceKlass 的字段表里类加载器相关数据ClassLoaderData记录类由哪个加载器加载。有两个东西经常被人误算进方法区静态变量的值以及 JIT 编译后的机器码。HotSpot 在 JDK 8 之后把静态字段的实际值放在了 java.lang.Class 对象内部并不在元空间JIT 编译产物在 CodeCache 中也不在方法区。所以“方法区存静态变量”这个说法规范层面没错但具体到 HotSpot 实现需要打个折。提示面试时如果有人问方法区存什么最好先声明“规范层面”和“HotSpot实现层面”再分层回答。很多八股文答案混着两个层面说容易接不住追问。2. klass 结构体HotSpot 用 C 给每个 Java 类建的户籍档案2.1 “klass”这个词是怎么来的klass 不是什么缩写就是 class 的另一种拼写。HotSpot 早期从 Strongtalk 这类 Smalltalk 虚拟机继承了不少设计理念其中很重要的一条就是 oop 与 klass 分离oopordinary object pointer是 Java 对象的“实例数据视图”klass 是对象的“类型信息视图”。一个 Java 对象在堆里不会把类的所有字段描述和方法代码复制一份。它只会保存自己的实例字段值然后用对象头里的一个指针指向自己的 klass。所有方法调用、类型判断、字段偏移计算运行时都先去 klass 上查。这样的设计让对象体积非常紧凑也让每个类在内存里只有一份元数据被所有实例共享。如果你对 HotSpot 源码感兴趣可以从这几个文件开始读src/hotspot/share/oops/klass.hpp、instanceKlass.hpp、instanceMirrorKlass.hpp、arrayKlass.hpp。klass 继承体系都定义在 oops 目录下。2.2 Klass 继承体系不同种类对象用不同的 klass 描述klass 不是一个孤零零的类它有完整的继承体系。不同的 Java 对象类型对应不同的 klass 子类。下面这个表基本覆盖了 HotSpot 里常见的 klass 种类Klass 子类描述的对象典型场景InstanceKlass普通 Java 类实例你自己写的类、String、ArrayList 等InstanceMirrorKlassjava.lang.Class 对象所有类的 Class 对象附带静态字段区InstanceClassLoaderKlassClassLoader 及其子类的实例自定义类加载器InstanceRefKlassReference 及其子类实例软引用、弱引用、虚引用ObjArrayKlass引用类型数组实例String[]、Object[]TypeArrayKlass基本类型数组实例int[]、byte[]、long[]普通类最常见它的 klass 就是 InstanceKlass。java.lang.Class 本身也是一个 Java 类但 HotSpot 给了它一个特殊待遇用 InstanceMirrorKlass 来描述原因是 Class 对象的布局远比普通对象复杂后面第三章会细说。2.3 InstanceKlass 内部到底装了什么InstanceKlass 是方法区里的核心结构。它不是一张表而是一棵互相引用的对象树。下面这几个成员几乎每次排查类加载问题都会碰到_name类的内部名格式是java/lang/String这种斜杠分割的写法_super指向父类的 klass 指针沿着它就能走出完整的继承链_fields字段描述表记录每个字段的名字、类型、访问标志和偏移量_methods方法对象数组每个元素是一个 MethodMethod 上挂着字节码、异常表、行号表_constants指向 ConstPool 对象也就是运行时常量池_vtable/_itable虚方法表和接口方法表Java 的方法分派就是靠查这两张表完成的_access_flags类的访问标志比如 public、final、abstract_java_mirror这个类在 Java 堆上对应的 java.lang.Class 对象引用_class_loader_data记录类加载器以及和它绑定的所有类元数据。vtable 值得单独说一句。invokevirtual 指令调用实例方法时JVM 不是每次都去遍历方法列表找目标方法而是直接查 vtable 的索引。子类重写父类方法时会调整自己在虚表中的槽位指向。接口调用则查 itable。这套机制极大提升了方法调用的速度而这一切都建立在 klass 对方法表的精细组织上。2.4 压缩类指针对象头里的 klass 指针为什么只有 4 字节每个 Java 对象都有一个对象头。在 64 位 JVM 上对象头由 mark word 和 klass pointer 组成。mark word 存放哈希码、锁状态、GC 年龄等信息klass pointer 指向这个对象对应的 klass。为了节省内存HotSpot 默认开启压缩类指针UseCompressedClassPointers。开启后对象头里的 klass pointer 不再是 8 字节裸指针而是一个 32 位的偏移值它的基地址是 Metaspace 里一块连续的 CompressedClassSpace。因为 klass 都在这块 1GB 左右的空间内用 32 位偏移就能覆盖全部地址。这里有个常见的面试进阶题为什么堆超过 32GB 时压缩对象指针和压缩类指针都会失效因为 32 位指针按 8 字节对齐后最多寻址 32GB。一旦堆超过这个范围对象指针变回 8 字节klass pointer 也跟着变回完整指针整个 JVM 的对象平均体积会明显增加。了解这一点你就知道为什么“超大堆不一定划算”了。3. Class 对象与 klass 的镜像绑定双向引用怎么绕晕大多数人的3.1 为什么需要两套东西不能一个顶两个一个很自然的问题是有了 klassJava 层为什么还要一个 java.lang.Class 对象直接让程序员操作 klass 不行吗答案很现实klass 是 JVM 内部的 C 对象程序员没有安全、稳定的方式直接操作它而反射、泛型、动态代理这些功能必须在 Java 层提供一个普通对象作为入口。这个设计在 HotSpot 里叫 Class Mirror。klass 负责真实的类型元数据Class 对象负责面向 Java 程序员的“外观”。两者像同一套信息的两层视图底层 C 结构可以任意演进只要 Java 层 API 不变业务代码毫无感知。这本质上是门面模式在 JVM 内核中的应用。3.2 klass._java_mirror 与 Class 内部隐藏槽位Class 对象和 klass 不是靠“名字相同”产生关联的它们互相持有引用。klass 这边有一个_java_mirror字段指向 Java 堆上对应的 java.lang.Class 实例Class 对象这边数量级上也有一个内部指针指向它表示的 klass。但这里有个非常容易搞混的细节Class 对象本身也是一个 Java 对象它的对象头里也有 klass pointer而这个指针指向的是 java.lang.Class 自己的 InstanceMirrorKlass而不是它“所表示的那个类”的 InstanceKlass。举个例子String.class这个对象对象头里的 klass pointer 指向 java.lang.Class 的 InstanceMirrorKlass它内部那个隐藏槽位才存放 java.lang.String 的 InstanceKlass 地址。也就是说每个 Class 对象其实有“两个 klass 指针”一个在对象头是它作为普通 java.lang.Class 实例的身份标识一个是内部隐藏槽位记录它到底代表哪个类。HotSpot 内部通过java_lang_Class::as_Klass(mirror)这类的工具方法从 Class 对象中取出真正绑定的 Klass 地址。这个隐藏槽位对 Java 层不可见但是 JVM 访问的关键路径。3.3 用一张表理清三层关系为了彻底搞清对象、Class 对象、klass 三者的关系我画了一张对照表实体所在位置对象头 klass 指向代表/描述的对象hello 字符串实例Java 堆java.lang.String 的 InstanceKlass一个字符串数据String.classJava 堆java.lang.Class 的 InstanceMirrorKlass内部隐藏槽位指向 String 的 InstanceKlassjava.lang.String 元数据Metaspace自身是 InstanceKlassString 类的结构和行为String[] 数组实例Java 堆String 数组的 ObjArrayKlass一个字符串数组数据String[].classJava 堆java.lang.Class 的 InstanceMirrorKlass内部隐藏槽位指向 ObjArrayKlass看到这你应该明白了String.class和new String()是完全不同的两种东西。前者是 Class 对象挂在 Class 类的类型体系下后者是 String 实例挂在 String 的类型体系下。两者通过 String 类的 InstanceKlass 联系起来。3.4 这层绑定在运行期如何被利用为什么这条绑定链路这么重要因为 JVM 很多核心操作都依赖它。比如getClass()是一个 native 方法它做的事就是读取对象头里的 klass pointer拿到 InstanceKlass 后返回它的_java_mirror。整个过程甚至不需要遍历任何链表时间复杂度 O(1)。比如instanceof和强制类型转换检查拿到对象的 klass 指针后沿着_super链向上逐级比较或者用 vtable/itable 里的快速判定机制判断对象是否能被转换成目标类型。反射操作更直接从 Class 对象的隐藏槽位找到 InstanceKlass再遍历_methods和_fields构造 Method 和 Field 对象返回给 Java 层。锁升级和 GC 也离不开 klass。对象头里的 mark word 负责记录偏向锁、轻量级锁状态而对象到底多大、字段怎么排布、怎么遍历全都定义在 klass 的布局信息里。GC 在移动对象时也要同步维护这些 klass 指针的指向。4. 一次类加载的完整链路klass 如何落地、Class 对象如何诞生4.1 入口defineClass 如何在 JVM 内部建起 klass类加载的第一入口通常是ClassLoader.loadClass()它经过findClass()后最终调用的是defineClass(byte[], int, int)这个 native 方法。这个调用会进入 JVM 内部的JVM_DefineClass然后交给ClassFileParser解析字节码。ClassFileParser做的事相当于一个 C 版本的“类文件解析器”检查魔数、版本号、常量池合法性读入字段和方法最后按照 InstanceKlass 的布局把数据填进去。klass 对象本身在元空间中分配内存。这一步完成后JVM 会调用初始化镜像的逻辑在 Java 堆上分配一个 java.lang.Class 对象并把它的地址写进 klass 的_java_mirror字段。这里有个顺序问题是先有 klass还是先有 Class 对象答案是先有 klass。defineClass 返回给调用方的 Class 对象本质上就是初始化完毕的 mirror。JVM 规范只是说加载阶段“应当”创建 Class 对象但 HotSpot 的实现在 defineClass 返回之前就把 mirror 弄好了所以你拿到的对象从一开始就完整绑定。4.2 链接阶段klass 是怎样一步步“长全”的类加载的链接阶段包括验证、准备、解析三步。验证和准备阶段klass 结构体里的访问标志、父类指针、字段表已经就位但一些依赖符号引用的部分还没完全定下来。解析阶段要做的事是把常量池里的符号引用逐步替换为直接引用。但 HotSpot 的解析默认是惰性的很多常量池项第一次被使用时才真正解析而不是类加载时一次性全部解完。所以你会看到同一个类的 ConstantPool 在运行期不断被填充klass 里的 vtable 和 itable 也会根据方法重写的情况动态调整。另外还有一个细节叫“类重写”class rewriting发生在链接早期。HotSpot 会在类加载后、执行前把字节码里的某些指令改写成更高效率的形态。例如把new指令的常量池索引替换成直接指向已解析类的指针减少运行时再去常量池里现查的损耗。这些改动同样落在 klass 关联的元数据上。4.3 静态字段到底存在哪里一个容易被问翻车的点八股文常背“方法区存放静态变量”但如果你在面试中说“HotSpot 的 JDK 8 里静态变量的值放在元空间”很可能被懂行的人纠正。HotSpot 的实现早就把静态字段的“值”挪到了 Class 对象上。InstanceMirrorKlass 在布局 java.lang.Class 对象时除了 Java 层可见的字段还会额外预留一块区域用来存类的静态字段值。类的每个静态字段都在 mirror 对象里有一个对应的槽位。InstanceKlass 里保存的只是静态字段的描述信息比如字段名、类型、偏移量真正存值得去 Class 对象里取。这样设计的好处是把静态字段的生命周期直接绑定到 Class 对象上。Class 对象在 Java 堆由 GC 统一管理静态字段的存活状态跟着对象的可达性走不用 JVM 再单独维护一套静态数据的管理逻辑。这也是为什么 JDK 8 之后静态字段导致的内存泄漏往往能从堆上找到根因。4.4 类卸载什么情况下 klass 会被清掉很多人以为元空间只涨不跌其实不是。当一个类不再被使用klass 完全可以被回收只是条件比较苛刻。HotSpot 大体要求类加载器不可达、该类的 Class 对象不可达、该类的所有实例也不可达满足这些条件后GC 才可能卸下这个类对应的 InstanceKlass归还元空间。系统类加载器加载的类基本不会卸载因为引导类加载器本身是 GC 根。需要关注的是自定义 ClassLoader。动态代理、热部署、CGLIB 生成的类都是由某个自定义加载器承载的。如果框架把旧 ClassLoader 一直放在缓存里不释放那么它加载的所有类的 klass 都永远可达Metaspace 只会只增不减。提示这里有个容易误解的点——Class 对象内部指向 klass 的隐藏槽位、klass 指向 Class 对象的_java_mirror这两个引用都是强引用为什么不会让类永远无法卸载因为 JVM 在类卸载判定时对镜像引用了特殊处理把 klass 当作 Class 对象的附属数据来遍历而不是当作独立的强可达对象。单纯的“互相引用”并不能阻止 GC 回收一个不可达的整体。5. 用 HSDB 亲手看一眼 klass 和 Class 对象的内存长相5.1 准备一个能停住的实验进程光看概念很难建立直觉最好的办法是用工具实际观察一次。先写一个简单的类public class KlassDemo { public static void main(String[] args) throws Exception { System.out.println(class loaded: KlassDemo.class.getName()); Thread.sleep(3600_000); } }编译运行后进程会停一小时趁这个时间用工具去“解剖”它。先拿到进程 IDjps -l假设输出里的 pid 是 12345接下来可以连接 HSDB。JDK 9 之后直接使用jhsdb hsdb --pid 12345JDK 8 需要手动加载 sa-jdi.jarjava -cp sa-jdi.jar sun.jvm.hotspot.HSDB再在打开的窗口里 attach 进程。5.2 HSDB 里能看到的 klass 视角HSDB 打开后工具栏里的 Tools - Class Browser 是最直观的入口。输入KlassDemo后会展示这个类的访问标志、父类、接口、字段列表、方法列表和常量池。这些数据不是 Java 反射 API 读取出来的而是 HSDB 直接解析 Metaspace 里的 InstanceKlass 结构得到的。如果你想看一个具体对象长什么样可以先用 Object Histogram 按类统计堆上的对象数量找到 java.lang.Class 实例。把某个 Class 对象放进 Inspector 面板你会看到对象头里的_mark和_metadata._klass。对 KlassDemo.class 本身做 Inspect_metadata._klass指向的是 Class 的 InstanceMirrorKlass而不是 KlassDemo 的 InstanceKlass而它的字段区域里藏着真正指向 KlassDemo InstanceKlass 的地址。生产环境不建议随便 attach HSDB它对进程有停顿影响。但在测试环境做一次这个实验对理解对象头、klass、mirror 三者关系的帮助非常大比读十篇文章都有用。5.3 更稳妥的诊断命令jcmd、jmap、jstat如果不想开 HSDB 图形界面可以用下面几条命令快速观察jcmd pid VM.class_hierarchy jcmd pid GC.class_histogram jcmd pid VM.metaspace jmap -clstats pid jstat -class pid 1000VM.class_hierarchy会打印类之间的继承关系这正是沿着 klass 的_super链走出来的结果。GC.class_histogram按类型统计堆对象能看到 java.lang.Class 实例的数量它通常等于当前存活加载的类数量。VM.metaspace非常关键它会输出 Metaspace 的总体容量、使用量、Chunk 分布以及 class space 和 non-class space 各自的占用。排查元空间增长时这条命令是第一手数据来源。jmap -clstats则按 ClassLoader 维度统计加载的类数量和元数据字节数能快速定位“到底是哪个加载器把元空间吃掉了”。jstat -class可以实时看类的加载和卸载数量变化。5.4 做一个动态生成类的小实验为了观察 klass 不断新增对元空间的影响可以跑一个动态生成代理类的小程序ClassLoader cl new URLClassLoader(new URL[0], ClassLoader.getSystemClassLoader()); for (int i 0; i 10000; i) { Class? c Proxy.getProxyClass(cl, new Class?[]{Runnable.class}); }注意Proxy.getProxyClass有缓存同一个 ClassLoader 加同一组接口只会生成一次代理类。要模拟膨胀得让 ClassLoader 不断变化比如循环创建新的 URLClassLoader或者每次用新的 Enhancer 配置来生成 CGLIB 代理。跑的时候配合jstat -class看 Loaded 数量再用VM.metaspace观察元空间增量你会直观看到每个新 klass 都在方法区留下了真实的内存足迹。6. 动态代理导致的 Metaspace 膨胀一次真实排查复盘6.1 现象运行几天后 Full GC 变频繁最后 Metaspace OOM以前接手过一个网关类服务单机内存和堆配置都合理但运行两三天后 GC 日志里 Full GC 次数开始明显上升再过一天直接抛java.lang.OutOfMemoryError: Metaspace。重启能恢复但过两天又复发。启动参数里其实已经设了-XX:MaxMetaspaceSize512m所以不是无限涨到物理内存耗尽而是被上限卡死后的必然崩溃。这段时间里堆内存一直很正常Eden 和 Old 区都没有压力问题明显不在对象分配上。于是重点转向元空间本身。6.2 数据元空间曲线和 ClassLoader 统计暴露了真凶用jcmd pid VM.metaspace观察Metaspace 的 used 数值稳定爬升重启后从几十 MB 起步两三天内逼近 512MB。class space 的占用和 non-class space 几乎同步增长说明新增的主要是类元数据而不是常量池之类的附属结构。再用jmap -clstats pid按 ClassLoader 排序发现一个自定义类加载器加载了三千多个类占用元空间字节数最大而且其中大量类名是形如com.xxx.Foo$$EnhancerBySpringCGLIB$$xxxx的代理类。这不是个别现象是同一个模式被不断重复生成。配合-XX:TraceClassLoading重新运行日志里刷出大量 CGLIB 代理类的加载记录。到这里方向已经从“Metaspace 为什么涨”变成了“谁在制造这么多代理类”。6.3 根因配置刷新让 ClassLoader 被缓存klass 永远无法卸载进一步排查发现服务接入了配置中心订阅每次配置变化都会触发一部分 Bean 的刷新重建。Spring 在刷新过程中会对目标 Bean 生成新的 CGLIB 代理类而每次重建都发生在新的 ApplicationContext 或新的 BeanFactory 里。坏就坏在旧的 BeanFactory 被另一个缓存组件长期持有导致旧 ClassLoader 一直没有失去引用。ClassLoader 不可达它加载的所有代理类的 klass 就都算可达Metaspace 回收机制完全失效。每刷新一次配置就有一批新的 InstanceKlass 落入元空间旧的却永远清不掉。表面看是 Metaspace 参数问题根子其实是 ClassLoader 的生命周期管理问题。6.4 修复与预防调参只是续命源头治理才是解药这次问题不是简单调大MaxMetaspaceSize能解决的那只是把崩溃时间往后拖。实际修复分几步对配置刷新事件做节流和合并避免高频变更反复触发 Bean 重建代理对象支持复用同一目标类型复用同一个 Enhancer而不是每次新建排查长期持有旧 ClassLoader 的缓存组件改为 WeakReference 或及时置空保留-XX:MaxMetaspaceSize作为兜底同时用 JMX 或监控平台盯着 Metaspace 趋势。修复后Metaspace 使用量稳定在原来的三分之一左右不再随时间线性上涨。这个案例给我的经验是遇到元空间持续增长第一件事不是调大小而是查 ClassLoader 是否被无意识缓存。只要类加载器的生命周期管住了klass 的“生老病死”就恢复了正常节奏。最后再分享一个实际体会理解和动手验证 klass 与 Class 对象的关系带来的收益远不止应付面试。很多线上问题——Metaspace OOM、反射性能瓶颈、动态代理异常、类卸载不生效——最终的归因都会落到这两个结构上。花一个下午用 HSDB 观察一次真实对象比背一百道 JVM 面试题都管用。
前几天帮一个准备跳槽的朋友对面试题在“方法区到底存了什么”这个问题上卡了很久。他能背出“类的元数据、运行时常量池、静态变量”但当我追问“这个元数据在 HotSpot 里具体长什么样你代码里拿到的 Xxx.class 对象和方法区里那块东西是不是同一个”他就接不下去了。这不怪他网上关于方法区的答案大多停留在 JVM 规范层面没有落到 HotSpot 的具体实现上。实际在 HotSpot 中方法区里的类信息核心是一套叫 klass 的 C 对象树而 Java 层还有一个 java.lang.Class 对象作为它的“镜像”两者长得完全不像、位置也不一样却靠着一组指针互相绑定。这篇我把这层关系彻底拆开覆盖原理、类加载链路、工具验证和线上排查看完能真正回答这一系列高频 Java 面试题而不是只背结论。1. 方法区不是一块黑盒先看类信息是以什么形态落地的1.1 从 .class 文件到内存结构类加载做了什么我们写的 Java 代码被 javac 编译成 .class 字节码文件但 JVM 运行时不可能每次都去读磁盘上的文件它必须在内存里建一套“运行期版本”的类结构。这个转换动作就是类加载子系统干的活读取字节流、解析结构、校验合法性最后按照 HotSpot 内部定义的 C 对象布局在内存里生成一棵 klass 对象。注意这里的关键点.class 文件不是被原样搬运到内存的而是被“重组”了。字节码文件里的常量池、字段表、方法表会被拆散后填进 HotSpot 自己的数据结构里。方法的字节码会被挂在 Method 对象上常量池会被转换成 ConstantPool 对象字段信息会整理成字段表。这套运行期结构就是方法区中“类的元信息”这个说法背后的实体。如果你只从 JVM 规范的角度看方法区存放的是类信息、运行时常量池、静态变量但如果你从 HotSpot 源码的角度看所谓的“类信息”是一组具体的 C 对象。其中最核心的是 InstanceKlass它相当于一个类在虚拟机内部的“户籍档案”。后面我们会花一整章来讲它内部到底装了什么。1.2 永久代和元空间方法区在 HotSpot 中的两段历史HotSpot 对方法区的实现经历过一次大改JDK 7 及以前用“永久代PermGen”JDK 8 开始换成“元空间Metaspace”。永久代位于 Java 堆内受堆大小限制默认值又往往不大所以只要动态生成类稍微多一点就容易抛java.lang.OutOfMemoryError: PermGen space。类加载器的数量、反射和代理类的使用强度直接决定永久代的压力。JDK 8 移除永久代后类元数据改到本地内存native memory由 Metaspace 管理器统一分配。元空间不再占用堆内存默认也没有上限只受操作系统可用内存限制。这带来一个好处类的元数据和堆对象分离堆 GC 时不用再扫描整块类元数据区域但坏处也很明显如果你不限制 MaxMetaspaceSize元空间可能悄悄涨到把物理内存耗尽。对比项 永久代JDK7及以前 元空间JDK8 存储位置 Java堆内 本地内存不在堆 默认上限 MaxPermSize默认值偏小 MaxMetaspaceSize默认无上限 GC参与 Full GC会扫描永久代 元空间回收与堆GC联动但不在堆内 OOM错误信息 PermGen space Metaspace另外还有一个容易忽略的事实GC 日志里看到的 Metaspace 通常分两块——class space 和 non-class space。class space 是专门放 klass 元数据的连续区域默认约 1GBnon-class space 放常量池、方法元数据等。很多调优场景只看总的 Metaspace 使用量却没注意到 CompressedClassSpace 可能先触顶。1.3 方法区里的实际组成不只是 klass方法区在 HotSpot 里并不是一个单一的存储结构而是由多种对象共同构成的内存区域。大致包括这么几类类与接口的元数据InstanceKlass、ArrayKlass 等 klass 结构体运行时常量池ConstantPool 对象保存类的符号引用和字面量方法元数据与字节码Method、ConstMethod每个 Java 方法的字节码都挂在这里字段描述信息字段名、类型、修饰符、偏移量存在于 InstanceKlass 的字段表里类加载器相关数据ClassLoaderData记录类由哪个加载器加载。有两个东西经常被人误算进方法区静态变量的值以及 JIT 编译后的机器码。HotSpot 在 JDK 8 之后把静态字段的实际值放在了 java.lang.Class 对象内部并不在元空间JIT 编译产物在 CodeCache 中也不在方法区。所以“方法区存静态变量”这个说法规范层面没错但具体到 HotSpot 实现需要打个折。提示面试时如果有人问方法区存什么最好先声明“规范层面”和“HotSpot实现层面”再分层回答。很多八股文答案混着两个层面说容易接不住追问。2. klass 结构体HotSpot 用 C 给每个 Java 类建的户籍档案2.1 “klass”这个词是怎么来的klass 不是什么缩写就是 class 的另一种拼写。HotSpot 早期从 Strongtalk 这类 Smalltalk 虚拟机继承了不少设计理念其中很重要的一条就是 oop 与 klass 分离oopordinary object pointer是 Java 对象的“实例数据视图”klass 是对象的“类型信息视图”。一个 Java 对象在堆里不会把类的所有字段描述和方法代码复制一份。它只会保存自己的实例字段值然后用对象头里的一个指针指向自己的 klass。所有方法调用、类型判断、字段偏移计算运行时都先去 klass 上查。这样的设计让对象体积非常紧凑也让每个类在内存里只有一份元数据被所有实例共享。如果你对 HotSpot 源码感兴趣可以从这几个文件开始读src/hotspot/share/oops/klass.hpp、instanceKlass.hpp、instanceMirrorKlass.hpp、arrayKlass.hpp。klass 继承体系都定义在 oops 目录下。2.2 Klass 继承体系不同种类对象用不同的 klass 描述klass 不是一个孤零零的类它有完整的继承体系。不同的 Java 对象类型对应不同的 klass 子类。下面这个表基本覆盖了 HotSpot 里常见的 klass 种类Klass 子类描述的对象典型场景InstanceKlass普通 Java 类实例你自己写的类、String、ArrayList 等InstanceMirrorKlassjava.lang.Class 对象所有类的 Class 对象附带静态字段区InstanceClassLoaderKlassClassLoader 及其子类的实例自定义类加载器InstanceRefKlassReference 及其子类实例软引用、弱引用、虚引用ObjArrayKlass引用类型数组实例String[]、Object[]TypeArrayKlass基本类型数组实例int[]、byte[]、long[]普通类最常见它的 klass 就是 InstanceKlass。java.lang.Class 本身也是一个 Java 类但 HotSpot 给了它一个特殊待遇用 InstanceMirrorKlass 来描述原因是 Class 对象的布局远比普通对象复杂后面第三章会细说。2.3 InstanceKlass 内部到底装了什么InstanceKlass 是方法区里的核心结构。它不是一张表而是一棵互相引用的对象树。下面这几个成员几乎每次排查类加载问题都会碰到_name类的内部名格式是java/lang/String这种斜杠分割的写法_super指向父类的 klass 指针沿着它就能走出完整的继承链_fields字段描述表记录每个字段的名字、类型、访问标志和偏移量_methods方法对象数组每个元素是一个 MethodMethod 上挂着字节码、异常表、行号表_constants指向 ConstPool 对象也就是运行时常量池_vtable/_itable虚方法表和接口方法表Java 的方法分派就是靠查这两张表完成的_access_flags类的访问标志比如 public、final、abstract_java_mirror这个类在 Java 堆上对应的 java.lang.Class 对象引用_class_loader_data记录类加载器以及和它绑定的所有类元数据。vtable 值得单独说一句。invokevirtual 指令调用实例方法时JVM 不是每次都去遍历方法列表找目标方法而是直接查 vtable 的索引。子类重写父类方法时会调整自己在虚表中的槽位指向。接口调用则查 itable。这套机制极大提升了方法调用的速度而这一切都建立在 klass 对方法表的精细组织上。2.4 压缩类指针对象头里的 klass 指针为什么只有 4 字节每个 Java 对象都有一个对象头。在 64 位 JVM 上对象头由 mark word 和 klass pointer 组成。mark word 存放哈希码、锁状态、GC 年龄等信息klass pointer 指向这个对象对应的 klass。为了节省内存HotSpot 默认开启压缩类指针UseCompressedClassPointers。开启后对象头里的 klass pointer 不再是 8 字节裸指针而是一个 32 位的偏移值它的基地址是 Metaspace 里一块连续的 CompressedClassSpace。因为 klass 都在这块 1GB 左右的空间内用 32 位偏移就能覆盖全部地址。这里有个常见的面试进阶题为什么堆超过 32GB 时压缩对象指针和压缩类指针都会失效因为 32 位指针按 8 字节对齐后最多寻址 32GB。一旦堆超过这个范围对象指针变回 8 字节klass pointer 也跟着变回完整指针整个 JVM 的对象平均体积会明显增加。了解这一点你就知道为什么“超大堆不一定划算”了。3. Class 对象与 klass 的镜像绑定双向引用怎么绕晕大多数人的3.1 为什么需要两套东西不能一个顶两个一个很自然的问题是有了 klassJava 层为什么还要一个 java.lang.Class 对象直接让程序员操作 klass 不行吗答案很现实klass 是 JVM 内部的 C 对象程序员没有安全、稳定的方式直接操作它而反射、泛型、动态代理这些功能必须在 Java 层提供一个普通对象作为入口。这个设计在 HotSpot 里叫 Class Mirror。klass 负责真实的类型元数据Class 对象负责面向 Java 程序员的“外观”。两者像同一套信息的两层视图底层 C 结构可以任意演进只要 Java 层 API 不变业务代码毫无感知。这本质上是门面模式在 JVM 内核中的应用。3.2 klass._java_mirror 与 Class 内部隐藏槽位Class 对象和 klass 不是靠“名字相同”产生关联的它们互相持有引用。klass 这边有一个_java_mirror字段指向 Java 堆上对应的 java.lang.Class 实例Class 对象这边数量级上也有一个内部指针指向它表示的 klass。但这里有个非常容易搞混的细节Class 对象本身也是一个 Java 对象它的对象头里也有 klass pointer而这个指针指向的是 java.lang.Class 自己的 InstanceMirrorKlass而不是它“所表示的那个类”的 InstanceKlass。举个例子String.class这个对象对象头里的 klass pointer 指向 java.lang.Class 的 InstanceMirrorKlass它内部那个隐藏槽位才存放 java.lang.String 的 InstanceKlass 地址。也就是说每个 Class 对象其实有“两个 klass 指针”一个在对象头是它作为普通 java.lang.Class 实例的身份标识一个是内部隐藏槽位记录它到底代表哪个类。HotSpot 内部通过java_lang_Class::as_Klass(mirror)这类的工具方法从 Class 对象中取出真正绑定的 Klass 地址。这个隐藏槽位对 Java 层不可见但是 JVM 访问的关键路径。3.3 用一张表理清三层关系为了彻底搞清对象、Class 对象、klass 三者的关系我画了一张对照表实体所在位置对象头 klass 指向代表/描述的对象hello 字符串实例Java 堆java.lang.String 的 InstanceKlass一个字符串数据String.classJava 堆java.lang.Class 的 InstanceMirrorKlass内部隐藏槽位指向 String 的 InstanceKlassjava.lang.String 元数据Metaspace自身是 InstanceKlassString 类的结构和行为String[] 数组实例Java 堆String 数组的 ObjArrayKlass一个字符串数组数据String[].classJava 堆java.lang.Class 的 InstanceMirrorKlass内部隐藏槽位指向 ObjArrayKlass看到这你应该明白了String.class和new String()是完全不同的两种东西。前者是 Class 对象挂在 Class 类的类型体系下后者是 String 实例挂在 String 的类型体系下。两者通过 String 类的 InstanceKlass 联系起来。3.4 这层绑定在运行期如何被利用为什么这条绑定链路这么重要因为 JVM 很多核心操作都依赖它。比如getClass()是一个 native 方法它做的事就是读取对象头里的 klass pointer拿到 InstanceKlass 后返回它的_java_mirror。整个过程甚至不需要遍历任何链表时间复杂度 O(1)。比如instanceof和强制类型转换检查拿到对象的 klass 指针后沿着_super链向上逐级比较或者用 vtable/itable 里的快速判定机制判断对象是否能被转换成目标类型。反射操作更直接从 Class 对象的隐藏槽位找到 InstanceKlass再遍历_methods和_fields构造 Method 和 Field 对象返回给 Java 层。锁升级和 GC 也离不开 klass。对象头里的 mark word 负责记录偏向锁、轻量级锁状态而对象到底多大、字段怎么排布、怎么遍历全都定义在 klass 的布局信息里。GC 在移动对象时也要同步维护这些 klass 指针的指向。4. 一次类加载的完整链路klass 如何落地、Class 对象如何诞生4.1 入口defineClass 如何在 JVM 内部建起 klass类加载的第一入口通常是ClassLoader.loadClass()它经过findClass()后最终调用的是defineClass(byte[], int, int)这个 native 方法。这个调用会进入 JVM 内部的JVM_DefineClass然后交给ClassFileParser解析字节码。ClassFileParser做的事相当于一个 C 版本的“类文件解析器”检查魔数、版本号、常量池合法性读入字段和方法最后按照 InstanceKlass 的布局把数据填进去。klass 对象本身在元空间中分配内存。这一步完成后JVM 会调用初始化镜像的逻辑在 Java 堆上分配一个 java.lang.Class 对象并把它的地址写进 klass 的_java_mirror字段。这里有个顺序问题是先有 klass还是先有 Class 对象答案是先有 klass。defineClass 返回给调用方的 Class 对象本质上就是初始化完毕的 mirror。JVM 规范只是说加载阶段“应当”创建 Class 对象但 HotSpot 的实现在 defineClass 返回之前就把 mirror 弄好了所以你拿到的对象从一开始就完整绑定。4.2 链接阶段klass 是怎样一步步“长全”的类加载的链接阶段包括验证、准备、解析三步。验证和准备阶段klass 结构体里的访问标志、父类指针、字段表已经就位但一些依赖符号引用的部分还没完全定下来。解析阶段要做的事是把常量池里的符号引用逐步替换为直接引用。但 HotSpot 的解析默认是惰性的很多常量池项第一次被使用时才真正解析而不是类加载时一次性全部解完。所以你会看到同一个类的 ConstantPool 在运行期不断被填充klass 里的 vtable 和 itable 也会根据方法重写的情况动态调整。另外还有一个细节叫“类重写”class rewriting发生在链接早期。HotSpot 会在类加载后、执行前把字节码里的某些指令改写成更高效率的形态。例如把new指令的常量池索引替换成直接指向已解析类的指针减少运行时再去常量池里现查的损耗。这些改动同样落在 klass 关联的元数据上。4.3 静态字段到底存在哪里一个容易被问翻车的点八股文常背“方法区存放静态变量”但如果你在面试中说“HotSpot 的 JDK 8 里静态变量的值放在元空间”很可能被懂行的人纠正。HotSpot 的实现早就把静态字段的“值”挪到了 Class 对象上。InstanceMirrorKlass 在布局 java.lang.Class 对象时除了 Java 层可见的字段还会额外预留一块区域用来存类的静态字段值。类的每个静态字段都在 mirror 对象里有一个对应的槽位。InstanceKlass 里保存的只是静态字段的描述信息比如字段名、类型、偏移量真正存值得去 Class 对象里取。这样设计的好处是把静态字段的生命周期直接绑定到 Class 对象上。Class 对象在 Java 堆由 GC 统一管理静态字段的存活状态跟着对象的可达性走不用 JVM 再单独维护一套静态数据的管理逻辑。这也是为什么 JDK 8 之后静态字段导致的内存泄漏往往能从堆上找到根因。4.4 类卸载什么情况下 klass 会被清掉很多人以为元空间只涨不跌其实不是。当一个类不再被使用klass 完全可以被回收只是条件比较苛刻。HotSpot 大体要求类加载器不可达、该类的 Class 对象不可达、该类的所有实例也不可达满足这些条件后GC 才可能卸下这个类对应的 InstanceKlass归还元空间。系统类加载器加载的类基本不会卸载因为引导类加载器本身是 GC 根。需要关注的是自定义 ClassLoader。动态代理、热部署、CGLIB 生成的类都是由某个自定义加载器承载的。如果框架把旧 ClassLoader 一直放在缓存里不释放那么它加载的所有类的 klass 都永远可达Metaspace 只会只增不减。提示这里有个容易误解的点——Class 对象内部指向 klass 的隐藏槽位、klass 指向 Class 对象的_java_mirror这两个引用都是强引用为什么不会让类永远无法卸载因为 JVM 在类卸载判定时对镜像引用了特殊处理把 klass 当作 Class 对象的附属数据来遍历而不是当作独立的强可达对象。单纯的“互相引用”并不能阻止 GC 回收一个不可达的整体。5. 用 HSDB 亲手看一眼 klass 和 Class 对象的内存长相5.1 准备一个能停住的实验进程光看概念很难建立直觉最好的办法是用工具实际观察一次。先写一个简单的类public class KlassDemo { public static void main(String[] args) throws Exception { System.out.println(class loaded: KlassDemo.class.getName()); Thread.sleep(3600_000); } }编译运行后进程会停一小时趁这个时间用工具去“解剖”它。先拿到进程 IDjps -l假设输出里的 pid 是 12345接下来可以连接 HSDB。JDK 9 之后直接使用jhsdb hsdb --pid 12345JDK 8 需要手动加载 sa-jdi.jarjava -cp sa-jdi.jar sun.jvm.hotspot.HSDB再在打开的窗口里 attach 进程。5.2 HSDB 里能看到的 klass 视角HSDB 打开后工具栏里的 Tools - Class Browser 是最直观的入口。输入KlassDemo后会展示这个类的访问标志、父类、接口、字段列表、方法列表和常量池。这些数据不是 Java 反射 API 读取出来的而是 HSDB 直接解析 Metaspace 里的 InstanceKlass 结构得到的。如果你想看一个具体对象长什么样可以先用 Object Histogram 按类统计堆上的对象数量找到 java.lang.Class 实例。把某个 Class 对象放进 Inspector 面板你会看到对象头里的_mark和_metadata._klass。对 KlassDemo.class 本身做 Inspect_metadata._klass指向的是 Class 的 InstanceMirrorKlass而不是 KlassDemo 的 InstanceKlass而它的字段区域里藏着真正指向 KlassDemo InstanceKlass 的地址。生产环境不建议随便 attach HSDB它对进程有停顿影响。但在测试环境做一次这个实验对理解对象头、klass、mirror 三者关系的帮助非常大比读十篇文章都有用。5.3 更稳妥的诊断命令jcmd、jmap、jstat如果不想开 HSDB 图形界面可以用下面几条命令快速观察jcmd pid VM.class_hierarchy jcmd pid GC.class_histogram jcmd pid VM.metaspace jmap -clstats pid jstat -class pid 1000VM.class_hierarchy会打印类之间的继承关系这正是沿着 klass 的_super链走出来的结果。GC.class_histogram按类型统计堆对象能看到 java.lang.Class 实例的数量它通常等于当前存活加载的类数量。VM.metaspace非常关键它会输出 Metaspace 的总体容量、使用量、Chunk 分布以及 class space 和 non-class space 各自的占用。排查元空间增长时这条命令是第一手数据来源。jmap -clstats则按 ClassLoader 维度统计加载的类数量和元数据字节数能快速定位“到底是哪个加载器把元空间吃掉了”。jstat -class可以实时看类的加载和卸载数量变化。5.4 做一个动态生成类的小实验为了观察 klass 不断新增对元空间的影响可以跑一个动态生成代理类的小程序ClassLoader cl new URLClassLoader(new URL[0], ClassLoader.getSystemClassLoader()); for (int i 0; i 10000; i) { Class? c Proxy.getProxyClass(cl, new Class?[]{Runnable.class}); }注意Proxy.getProxyClass有缓存同一个 ClassLoader 加同一组接口只会生成一次代理类。要模拟膨胀得让 ClassLoader 不断变化比如循环创建新的 URLClassLoader或者每次用新的 Enhancer 配置来生成 CGLIB 代理。跑的时候配合jstat -class看 Loaded 数量再用VM.metaspace观察元空间增量你会直观看到每个新 klass 都在方法区留下了真实的内存足迹。6. 动态代理导致的 Metaspace 膨胀一次真实排查复盘6.1 现象运行几天后 Full GC 变频繁最后 Metaspace OOM以前接手过一个网关类服务单机内存和堆配置都合理但运行两三天后 GC 日志里 Full GC 次数开始明显上升再过一天直接抛java.lang.OutOfMemoryError: Metaspace。重启能恢复但过两天又复发。启动参数里其实已经设了-XX:MaxMetaspaceSize512m所以不是无限涨到物理内存耗尽而是被上限卡死后的必然崩溃。这段时间里堆内存一直很正常Eden 和 Old 区都没有压力问题明显不在对象分配上。于是重点转向元空间本身。6.2 数据元空间曲线和 ClassLoader 统计暴露了真凶用jcmd pid VM.metaspace观察Metaspace 的 used 数值稳定爬升重启后从几十 MB 起步两三天内逼近 512MB。class space 的占用和 non-class space 几乎同步增长说明新增的主要是类元数据而不是常量池之类的附属结构。再用jmap -clstats pid按 ClassLoader 排序发现一个自定义类加载器加载了三千多个类占用元空间字节数最大而且其中大量类名是形如com.xxx.Foo$$EnhancerBySpringCGLIB$$xxxx的代理类。这不是个别现象是同一个模式被不断重复生成。配合-XX:TraceClassLoading重新运行日志里刷出大量 CGLIB 代理类的加载记录。到这里方向已经从“Metaspace 为什么涨”变成了“谁在制造这么多代理类”。6.3 根因配置刷新让 ClassLoader 被缓存klass 永远无法卸载进一步排查发现服务接入了配置中心订阅每次配置变化都会触发一部分 Bean 的刷新重建。Spring 在刷新过程中会对目标 Bean 生成新的 CGLIB 代理类而每次重建都发生在新的 ApplicationContext 或新的 BeanFactory 里。坏就坏在旧的 BeanFactory 被另一个缓存组件长期持有导致旧 ClassLoader 一直没有失去引用。ClassLoader 不可达它加载的所有代理类的 klass 就都算可达Metaspace 回收机制完全失效。每刷新一次配置就有一批新的 InstanceKlass 落入元空间旧的却永远清不掉。表面看是 Metaspace 参数问题根子其实是 ClassLoader 的生命周期管理问题。6.4 修复与预防调参只是续命源头治理才是解药这次问题不是简单调大MaxMetaspaceSize能解决的那只是把崩溃时间往后拖。实际修复分几步对配置刷新事件做节流和合并避免高频变更反复触发 Bean 重建代理对象支持复用同一目标类型复用同一个 Enhancer而不是每次新建排查长期持有旧 ClassLoader 的缓存组件改为 WeakReference 或及时置空保留-XX:MaxMetaspaceSize作为兜底同时用 JMX 或监控平台盯着 Metaspace 趋势。修复后Metaspace 使用量稳定在原来的三分之一左右不再随时间线性上涨。这个案例给我的经验是遇到元空间持续增长第一件事不是调大小而是查 ClassLoader 是否被无意识缓存。只要类加载器的生命周期管住了klass 的“生老病死”就恢复了正常节奏。最后再分享一个实际体会理解和动手验证 klass 与 Class 对象的关系带来的收益远不止应付面试。很多线上问题——Metaspace OOM、反射性能瓶颈、动态代理异常、类卸载不生效——最终的归因都会落到这两个结构上。花一个下午用 HSDB 观察一次真实对象比背一百道 JVM 面试题都管用。
)
