摘要本文用大量示意图和代码示例系统拆解 Java 8 的 JVM 运行时内存结构程序计数器、虚拟机栈、本地方法栈、Java 堆、元空间、运行时常量池、字符串常量池与直接内存。重点讲清楚「方法区去哪了」「运行时常量池和字符串常量池到底是什么关系」「String 对象到底存哪里」这些高频纠结点帮你一次性建立清晰、不打架的内存模型。1. 为什么你总在方法区和常量池里绕不出来很多同学背 JVM 内存模型时都能脱口而出「堆、栈、方法区、程序计数器」但只要一被追问「字符串常量池在堆里还是在方法区里」「Java 8 还有没有方法区」「运行时常量池和字符串常量池是一回事吗」马上就乱了。混乱的根源其实不是记忆力而是这几点版本差异叠加Java 7、Java 8 对方法区和常量池的位置做了两次关键调整而很多资料还停留在旧版本新旧结论混着看自然打架。「逻辑分区」和「物理实现」混为一谈方法区是一种「规范层面的逻辑区域」它到底落在哪块内存不同 JDK 实现可以不一样。常量池有多个class 文件常量池、运行时常量池、字符串常量池不是一个东西但都叫「常量池」。这篇文章以Java 8HotSpot 虚拟机为准把这几个概念一次理清。读完你会得到一个稳定、自洽的内存模型而不是一堆互相矛盾的知识点。2. 一张图看懂 JVM 运行时数据区Java 虚拟机规范把运行时数据区划分为几块其中「线程私有」和「线程共享」是最重要的一次切分区域是否线程共享存放内容主要异常程序计数器线程私有当前线程正在执行的字节码指令地址无Java 虚拟机栈线程私有栈帧、局部变量表、操作数栈、返回值StackOverflowError、OutOfMemoryError本地方法栈线程私有本地方法native调用信息StackOverflowError、OutOfMemoryErrorJava 堆线程共享对象实例、数组、字符串常量池OutOfMemoryError元空间线程共享类的元信息、运行时常量池OutOfMemoryError直接内存非 JVM 规范运行时数据区NIO 的 DirectByteBuffer 等OutOfMemoryError先记住一个总的判断准则「对象和数组去堆类的元数据和常量池去元空间方法的局部变量和调用信息去栈」。后面的内容都是围绕这三句话展开的。3. 程序计数器最不起眼却不可或缺程序计数器Program Counter Register是一块很小的内存区域可以理解为「当前线程执行到了哪一行字节码」的指示器。它有四个特点线程私有每个线程都有自己的程序计数器互不干扰。唯一不抛 OutOfMemoryError 的区域它只保存一个地址或空值大小固定。执行 Java 方法时记录字节码地址分支、循环、跳转、异常、线程恢复都靠它。执行 native 方法时为 undefined本地方法已经不是 JVM 字节码不需要记录字节码地址。程序计数器是 JVM 内存模型里最省心的角色理解成本低面试中记住「线程私有、不会 OOM、记录字节码指令地址」这三点就足够。4. Java 虚拟机栈方法调用的骨架4.1 栈帧的构成每个线程在创建时都会分配一个虚拟机栈。每当一个方法被执行JVM 就会创建一个「栈帧」压入栈顶方法返回或抛出异常时栈帧出栈。栈帧主要包含局部变量表存放方法参数和内部定义的局部变量。它的容量单位是「变量槽Slot」每个 Slot 通常可容纳一个 32 位以内的类型long 和 double 这类 64 位类型占用两个 Slot。操作数栈字节码指令执行时的「工作台」进行算术运算、参数传递、返回值暂存等。动态链接指向运行时常量池中该方法的引用支持运行时多态。方法返回地址方法结束后回到调用方的位置。4.2 局部变量表的一个易错点局部变量表里的「引用类型」只保存引用指针对象本体在堆里。因此「局部变量存放在栈里」这句话严格来说只对了一半变量本身引用在栈的局部变量表里但它指向的对象在堆里。4.3 栈的异常StackOverflowError 与 OOM栈容量是有限的。如果线程请求的栈深度超过允许的最大深度会抛StackOverflowError如果在动态扩展时无法申请到足够内存会抛OutOfMemoryError。下面是一个无限递归触发栈溢出的经典示例javapublic class StackOverflowDemo { private static int count 0; public static void recursion() { count; recursion(); } public static void main(String[] args) { try { recursion(); } catch (StackOverflowError e) { System.out.println(栈深度: count); } } }运行后会看到程序最终抛出StackOverflowError。可以通过-Xss参数调整栈大小例如-Xss1m表示每个线程栈空间为 1MB。5. 本地方法栈留给 native 的栈本地方法栈和虚拟机栈的作用非常相似区别只在于虚拟机栈为 JVM 执行 Java 方法字节码服务而本地方法栈为 JVM 使用到的 native 方法服务。Object.hashCode()、Thread.start0()这类被native修饰的方法就走本地方法栈。在 HotSpot 虚拟机中本地方法栈和虚拟机栈直接合并实现所以日常几乎不需要单独区分只要知道有这个逻辑分区即可。6. Java 堆对象的家园6.1 堆的定位Java 堆是 JVM 所管理内存中最大的一块所有线程共享在虚拟机启动时创建。它的唯一目的就是存放对象实例和数组。「几乎所有的对象实例都在这里分配内存」——之所以说「几乎」是因为 JIT 编译器的发展带来栈上分配、标量替换等优化少部分对象可能在编译后被优化到栈上但从 JVM 规范角度看对象就是该在堆上。6.2 Java 8 下的堆分区分代垃圾回收Java 8 的堆在物理上依然是连续或不连续的内存逻辑上通常划分为新生代Young Generation由 Eden 区加两个 Survivor 区S0、S1也常写作 From、To构成默认比例 8:1:1。新对象优先在 Eden 分配Minor GC 后幸存的对象进入 Survivor。老年代Old Generation存放长期存活的对象触发 Major GC / Full GC。堆可以通过-Xms设置初始大小、-Xmx设置最大大小。它是垃圾收集器工作的主战场也是所有 JVM 调优的核心观察对象。6.3 堆为什么会 OOM当堆里全是存活对象、垃圾收集器也回收不出足够空间给新对象分配时就会抛OutOfMemoryError: Java heap space。典型制造堆溢出的代码如下javaimport java.util.ArrayList; import java.util.List; public class HeapOOMDemo { public static void main(String[] args) { Listbyte[] list new ArrayList(); while (true) { list.add(new byte[1024 * 1024]); } } }在-Xmx设置较小时运行会很快抛出堆溢出异常。堆调优不是无脑加大内存而要先分析是内存泄漏还是内存不足分别用对象直方图、GC 日志、堆转储来定位。7. 方法区去哪了元空间正式登场这一节是全文的重点也是「方法区和常量池」纠结点的主战场。7.1 方法区是一个规范概念Java 虚拟机规范定义了「方法区Method Area」它是各个线程共享的内存区域用于存储已被虚拟机加载的类型信息类名、访问修饰符、字段描述、方法信息等常量静态变量即时编译器编译后的代码缓存等。规范只规定「要有这样一个逻辑区域」但不规定它必须落在堆内还是堆外具体怎么实现由各虚拟机自己决定。HotSpot 在不同版本就给出了不同答案。7.2 HotSpot 的演进从永久代到元空间JDK 版本HotSpot 实现所在位置默认容量Java 7 及之前永久代PermGen堆内存的逻辑部分默认较小容易溢出Java 8 开始元空间Metaspace本地内存堆外默认不设上限受系统内存限制永久代有一个很头疼的问题它和堆共享空间默认容量偏小而类的元数据会随着动态加载持续膨胀动不动就OutOfMemoryError: PermGen space。Java 8 用「元空间」彻底取代永久代把类的元数据搬到了本地内存Native Memory不再挤占堆空间容量上限也大幅提升。7.3 元空间的溢出元空间既然搬到本地内存自然也不会永不溢出。大量重复生成类例如 CGLIB 动态代理、反射频繁加载时本地内存会被吃光抛OutOfMemoryError: Metaspace。元空间相关参数-XX:MetaspaceSize触发元空间垃圾回收的初始阈值。-XX:MaxMetaspaceSize元空间最大大小默认无限制。-XX:MinMetaspaceFreeRatio与-XX:MaxMetaspaceFreeRatio控制元空间 GC 后剩余空间的比例。生产环境建议根据实际类加载量设置MaxMetaspaceSize避免元空间无限制膨胀拖垮系统。8. 三个「常量池」必须分清楚8.1 Class 文件常量池每个.class文件里都有一个常量池Constant Pool Table它是编译器为每个类和接口生成的静态数据存放两大类常量字面量文本字符串、被声明为 final 的常量值等。符号引用类和接口的全限定名、字段的名称和描述符、方法的名称和描述符等。它存在于磁盘上的 class 文件中属于「编译期」还不是运行时内存。用javap -v反编译时看到的Constant pool:列表就是它。8.2 运行时常量池类被加载到元空间后class 文件常量池中的内容会被装入运行时常量池Runtime Constant Pool。它是 class 文件常量池在内存中的「动态形态」存放在元空间里。和 class 文件常量池相比运行时常量池更具动态性除了 class 文件中定义的常量运行期间还可以把新的常量放入池中最典型的就是String.intern()方法。8.3 字符串常量池字符串常量池String Pool / String Intern Pool是运行时常量池中专门存放字符串字面量和 intern 后的字符串引用的那部分。从 Java 7 开始HotSpot 把字符串常量池从方法区永久代挪到了 Java 堆。所以Java 7 前字符串常量池在方法区永久代。Java 7 起字符串常量池在 Java 堆中。Java 8 起运行时常量池随整个方法区搬到元空间但字符串常量池仍然在堆中它只是逻辑上受运行时常量池管理。这就是最核心的认知「运行时常量池在元空间字符串常量池在堆里」两者不是一回事不能混用「常量池」这一个词。9. String 到底在哪里串起全部概念搞清了区域后我们用最经典的String问题把前面所有概念串起来。9.1 字面量创建的字符串javaString s1 hello;这行代码发生了什么编译期把字面量hello放进 class 文件常量池。类加载时该字面量进入运行时常量池。执行到这行代码时JVM 会到字符串常量池查找是否有值为hello的字符串。若有直接把池中字符串的引用赋给s1若没有则在堆中创建字符串对象把引用放入字符串常量池再返回该引用。那么hello这个 String 对象本体存在哪里答案堆里。字符串常量池里存的其实是「指向堆中 String 对象的引用」而不是把对象搬进池里边占一份独立空间现代 HotSpot 实现如此这也是 Java 7 把常量池挪到堆里的原因之一。9.2 new 出来的字符串javaString s2 new String(hello);new String(hello)会先在堆中创建一个全新的 String 对象赋给s2。所以s1 s2为falses1指向字符串常量池记录的那个堆中对象s2指向 new 出来的另一个堆中对象。javaString s1 hello; String s2 new String(hello); System.out.println(s1 s2); // false引用不同 System.out.println(s1.equals(s2)); // true内容相同9.3 intern() 的作用String.intern()是一个 native 方法。它的语义是如果字符串常量池中已经存在一个等于此 String 对象的字符串则返回池中那个字符串的引用否则把当前字符串对象的引用记录到池中并返回该引用。javaString s3 new String(hello).intern(); System.out.println(s1 s3); // trueintern 后指向字符串常量池中的同一对象在 Java 7 之前intern 后的字符串字面量会被复制到永久代成本高、容易 OOMJava 7 起字符串常量池挪到堆里intern 只需在堆中记录引用成本大幅降低。这也是为什么很多依赖 intern 做字符串去重的框架例如某些 JSON 解析器、ORM 框架在 Java 7 之后性能表现更好。9.4 字符串拼接的陷阱字符串拼接在不同写法下创建对象的数量完全不同javaString a he llo; // 编译期直接优化为 hello只产生一个对象 String b he; String c b llo; // 运行期用 StringBuilder 拼接产生新的 String 对象 System.out.println(a hello); // true System.out.println(c hello); // false要点总结编译期可确定的字面量拼接javac 会直接合并成一个字面量放入 class 文件常量池。含变量的拼接编译后等价于new StringBuilder().append(...).toString()结果是一个新的 String 对象位于堆中不会自动进入字符串常量池。若希望运行时拼接结果进入字符串常量池需要显式调用intern()。这也是「不要在循环里用拼接字符串」这条经验法则的底层原因每次拼接都会生成新的 StringBuilder 和新的 String既增加 CPU 开销也增加 GC 压力。10. 直接内存JVM 规范之外的「第八块区域」直接内存Direct Memory并不是 Java 虚拟机规范定义的运行时数据区但在实际应用中非常常见尤其是在 NIO、Netty、Kafka 这类高性能框架中。10.1 直接内存是什么直接内存是通过java.nio.ByteBuffer.allocateDirect()分配的堆外内存。它不在 Java 堆里也不受-Xmx约束而是直接由操作系统管理。javaByteBuffer buffer ByteBuffer.allocateDirect(1024 * 1024);它的主要优势是在文件 IO 和网络 IO 时可以避免 Java 堆和内核缓冲区之间的数据拷贝从而提升吞吐量。代价是分配和释放的成本比堆内存更高且不受 GC 直接管理。10.2 直接内存的回收直接内存对象本身是一个DirectByteBuffer它存在于 Java 堆中真正的大块内存则由Unsafe分配在堆外。当DirectByteBuffer对象被 GC 回收时会通过Cleaner机制触发堆外内存的释放。因此直接内存的回收时机依赖 GC。如果堆内存充足、GC 迟迟不发生堆外内存就可能一直无法释放最终抛OutOfMemoryError: Direct buffer memory。10.3 直接内存相关参数-XX:MaxDirectMemorySize直接内存上限。不设置时默认与-Xmx相当。-XX:DisableExplicitGC禁止代码中显式调用System.gc()。开启了它之后即使代码里手动触发 GC也不会立即回收直接内存使用 Netty 等框架时要特别注意。-Dio.netty.maxDirectMemoryNetty 自身的直接内存上限与 JVM 参数共同决定可用空间。排查直接内存溢出时推荐结合jcmd pid VM.native_memory或Native Memory TrackingNMT工具观察堆外内存的实际占用。11. 一张表串起所有概念把前面的内容汇总成一张对照表方便随时查阅概念位置线程归属生命周期程序计数器JVM 内部寄存器抽象线程私有随线程创建、销毁虚拟机栈JVM 内存线程私有随线程创建、销毁本地方法栈JVM 内存HotSpot 与虚拟机栈合并线程私有随线程创建、销毁Java 堆JVM 内存线程共享随 JVM 启动、关闭元空间本地内存Native Memory线程共享随 JVM 启动、关闭运行时常量池元空间线程共享随类加载进入、随类卸载释放字符串常量池Java 堆线程共享随 JVM 启动、关闭直接内存本地内存线程共享由 GC 或显式释放触发结合这张表再看面试常问的几个问题答案就非常清楚了「字符串常量池在哪」——Java 7 起在 Java 堆。「运行时常量池在哪」——Java 8 起在元空间。「元空间在哪」——本地内存不在堆里。「方法区还在吗」——作为规范概念存在HotSpot 的实现从永久代换成了元空间。「String 对象本体在哪」——堆里字符串常量池中存放的是它的引用。12. 常见误区与面试问答12.1 「Java 8 之后没有方法区了」这是最常见的误读。准确说法是方法区作为 JVM 规范里的逻辑区域一直存在只是 HotSpot 的实现从永久代变成了元空间。说「没有方法区」并不严谨说「没有永久代」才是对的。12.2 「字符串常量池就是运行时常量池」两者是包含关系而非等同关系。字符串常量池只是运行时常量池中处理字符串的那一部分而且在 Java 7 之后它已经被搬到堆里与其他常量分开存放。12.3 「常量池都在方法区里」这句话在 Java 7 之前勉强说得通但 Java 7 之后字符串常量池在堆里、Java 8 之后运行时常量池在元空间里再用「都在方法区」这个结论就会产生矛盾。12.4 「对象一定分配在堆上」JIT 编译器通过逃逸分析可能把不会逃逸的对象分配在栈上栈上分配或者把对象拆解为若干标量标量替换。所以严格来说对象不一定都在堆上但这是 JVM 的实现优化不影响规范层面「对象在堆中分配」的结论。12.5 「栈溢出就是内存不够」不是。StackOverflowError和OutOfMemoryError是两种不同的异常前者是栈深度超限例如无限递归后者是内存不足。HotSpot 中虚拟机栈大小固定由-Xss决定所以栈相关的问题通常表现为StackOverflowError而不是 OOM。13. 总结Java 8 的内存结构并不复杂混乱往往来自三点版本差异、逻辑与实现的混淆、以及多个「常量池」共用同一个名词。把本文的结论浓缩成几句话线程私有区程序计数器、虚拟机栈、本地方法栈。线程共享区Java 堆、元空间。对象在堆里类的元数据在元空间方法的局部变量在栈里。字符串常量池在堆里运行时常量池在元空间class 文件常量池在磁盘上。直接内存不属于 JVM 运行时数据区但同样会引起 OOM。