先把话放这儿JVM内存模型这东西你要是只为了应付面试背那几张图用不了两周就会忘干净。但你要是真在线上遇到过OOM、GC卡顿、接口突然超时再回头啃这块内容你会发现每一个概念背后都对应着一场血泪事故。这篇文章我不打算给你复述教科书而是按实际排查问题的思路把内存模型拆开揉碎讲清楚——哪些区域是线程共享的、哪些是线程私有的、对象从一个区跑到另一个区要经过哪些关卡、每个区域内存不够时分别报什么错。搞懂这些你才算真正拿到了JVM调优和问题定位的入场券。1. 运行时数据区全景先搞清楚JVM把内存花在了哪里1.1 五个核心区域与两类“线程归属”JVM在运行Java程序时会把自己管理的内存划分成几个不同的数据区域。这个划分不是拍脑袋定的而是根据“数据生命周期”和“线程访问方式”两个维度来设计的。按照《Java虚拟机规范》的划分整体上分为五大块程序计数器Program Counter Register、虚拟机栈JVM Stack、本地方法栈Native Method Stack、堆Heap、方法区Method Area。先说线程归属这是最容易理解也最容易混淆的点。程序计数器、虚拟机栈、本地方法栈这三个区域是线程私有的——也就是说每个线程都有一份独立的副本线程之间互不干扰生命周期跟线程同步线程创建时就分配线程结束时就回收。而堆和方法区是线程共享的——所有线程都能访问同一块区域里的数据所以这两个区域才是并发问题和内存分配冲突的重灾区。为什么要这么设计道理很简单栈是方法调用的载体每个线程都在执行不同的方法调用链当然要各存各的而对象和类元数据是“公共资源”需要被多处引用自然要共享。这个设计哲学贯穿了整个JVM内存模型的阅读逻辑。1.2 各区域职责一览一张表说清“谁负责什么”用一张表快速把五个区域的核心职责和异常情况列出来后面每个区域再详细说。区域名称线程归属存什么内容内存不足时的报错程序计数器线程私有当前线程正在执行的字节码行号指示器唯一不会OOM的区域虚拟机栈线程私有栈帧局部变量表、操作数栈、动态链接、方法出口等StackOverflowError 或 OutOfMemoryError本地方法栈线程私有为native方法执行分配的空间StackOverflowError 或 OutOfMemoryErrorJava堆线程共享几乎所有对象实例和数组OutOfMemoryError: Java heap space方法区线程共享类元信息、常量、静态变量、JIT编译后的代码OutOfMemoryError: MetaspaceJDK8及以后这个表格建议你在排查问题时对照着看——看到报错信息里的关键字基本就能锁定是哪块区域出了问题。比如Java heap space那必然是堆满了Metaspace那就是方法区的问题而栈溢出通常打印的是StackOverflowError。1.3 先泼一盆冷水别把“JVM内存模型”和“Java内存模型”搞混写这篇文章前我刷过不少JVM相关的讨论帖发现好多人在聊“内存模型”时谈的是完全不同的东西。这里必须做个明确区分JVM内存模型Runtime Data Area本文讲的内容关注的是JVM运行时怎么划分和管理内存哪些区域存对象、哪些区域存栈帧、怎么分配和回收。Java内存模型Java Memory ModelJMMJSR-133定义的一套并发内存抽象关注的是多线程之间的可见性、原子性、有序性核心是主内存与工作内存的关系以及happens-before规则。面试时这两个概念经常被连着问你要是把“堆、栈、方法区”和“主内存、工作内存”混为一谈考官基本就能判断你理解得不够深。我给你的建议是聊JVM内存模型时往“运行时数据区划分、内存分配策略、OOM类型”这些方向靠聊JMM时再谈volatile、synchronized、内存屏障这些。两者是不同维度的东西千万别搅在一起。2. 堆对象的“居住地”也是内存问题的重灾区2.1 堆的定位与内存分代堆是JVM管理内存中最大的一块也是所有线程共享的区域。它存在的目的只有一个存放对象实例。你在代码里new出来的绝大多数对象——包括包装类实例、String对象、集合里的节点、数组——都在堆上分配空间。虚拟机规范里有句话“几乎所有的对象实例都在这里分配内存”注意是“几乎”因为JDK里还有一个叫栈上分配的优化技术借助逃逸分析可以让某些不会逃逸出方法作用域的小对象直接在栈帧上分配省去了堆分配的损耗。不过在绝大多数情况下、在绝大多数JVM实现里堆就是对象的“家”。既然堆是共享的、体量最大的GC垃圾回收的主战场也自然在堆上。为了方便回收和分配JVM把堆区划分成了两块逻辑上的子区域新生代Young Generation新对象优先在这里分配。新生代内部又分为1个Eden区和2个Survivor区默认比例8:1:1可以用-XX:SurvivorRatio调整。新对象先进入EdenMinor GC后幸存的移动到Survivor区。老年代Old Generation存活时间较长的对象最终会进入这里Major GC或者说Full GC主要针对这个区域。这个分代设计本质上就是一种“按存活概率分组”的优化策略绝大多数对象生命周期极短把它们集中放到新生代每次GC只扫描这一小块区域用复制算法快速清掉“短命对象”少数活很久的对象提升到老年代用标记-整理或标记-清除算法处理避免被反复复制搬运。2.2 对象晋升的规则从一个区到另一个区的“晋级之路”对象不会平白无故从新生代跳到老年代它的迁移遵循一套明确的判定规则。我把这套规则汇总一下这些细节在排查内存问题和做GC调优时非常关键年龄阈值对象在Survivor区每熬过一次Minor GC年龄加1。默认情况下年龄达到15对应参数-XX:MaxTenuringThreshold15时晋升到老年代。CMS收集器可以调整这个值。动态年龄判定JVM不会死板地等对象到15岁才晋升。如果Survivor区中相同年龄所有对象大小的总和大于Survivor区容量的一半那么年龄大于等于这些对象年龄的那批对象可以直接晋升不用等到15岁。这其实是个保护机制防止Survivor空间不够用。大对象直接进入老年代如果配置了-XX:PretenureSizeThreshold单位字节那么超过这个阈值的“大对象”会直接在老年代分配。这样做的目的是避免大对象在Eden区和两个Survivor区之间反复复制那是非常昂贵的操作。Minor GC后存活对象放不下Survivor区避险兜底策略Survivor区空间不足时存活对象直接晋升到老年代。理解这套晋升规则后你看GC日志会很明显——那些微妙的内存波动根本不是玄学而是对象在这些区域之间流动的必然结果。如果你在日志里发现老年代快速增长大概率是出现了大对象或者Survivor空间设置过小导致提前晋升。2.3 堆参数配置思路不是越大越好很多新手容易犯一个毛病觉得堆开得越大性能就越好。然后就-Xmx8g、-Xms8g往上怼结果Full GC一次要停顿好几秒接口全都堵死。这里要搞清楚一个核心关系堆越大GC单次耗时越长。堆得能装下所有需要存活的数据但不要盲目堆大。我的建议是-Xms初始堆大小与-Xmx最大堆大小建议设置相同避免堆扩容和缩容带来的性能抖动。新生代大小可用-Xmn设置经验值是堆的1/3到1/4左右。新生代太小会导致对象频繁晋升到老年代老年代一满就触发Full GC新生代太大则会压缩老年代空间同样容易触发Full GC。如果你在Eden区和Survivor区之间反复看到大量对象“溢出”到老年代可以通过增大-XX:SurvivorRatio的方式比如从8调成16或者更大给Survivor留出更多空间缓冲。还有一个很多人忽略的点对象并不是只从Eden区分配。TLABThread-Local Allocation Buffer机制下每个线程在Eden区里都会预申请一块私有空间线程内分配对象时优先在这里分配避免多个线程抢占同一块堆内存时的同步开销。你可以把这个理解成“路边摊台面前给每个窗口划了一道专属排队线”。这也是为什么并发高的服务里堆的分配效率依然能保持较高水准的原因之一。3. 虚拟机栈每个线程背后的“方法调用记账本”3.1 栈帧里到底放了哪些东西虚拟机栈描述的是Java方法执行时的线程内存模型。每次方法调用JVM就会创建一个**栈帧Stack Frame**压入栈中方法执行完毕栈帧随即弹出。这个“先进后出”的结构大家应该很熟——但栈帧内部的结构很容易被忽略。一个标准栈帧包含以下几个部分局部变量表Local Variables Array存放方法参数和方法内部定义的局部变量。它的容量以**变量槽Slot**为单位32位以内的类型占用1个Slotdouble和long占用2个Slot。局部变量表是在编译期就确定大小的所以方法运行期间不会动态改变它的容量。操作数栈Operand Stack可以理解成一个临时的“计算工作台”。字节码指令在执行时会把操作数压入操作数栈运算后再把结果弹出来。比如执行iadd整数加法时就是从操作数栈弹出两个数相加后再把结果压回去。动态链接Dynamic Linking每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用用来在运行期将符号引用解析为直接引用。方法返回地址方法正常退出或异常退出时需要恢复到调用该方法的上层方法的执行位置。正常退出时调用者的程序计数器值会被恢复异常退出时返回地址通过异常处理器表确定。附加信息虚拟机规范允许不同的JVM实现增加一些规范里没有描述的信息比如与调试、性能监控相关的数据。3.2 局部变量表与操作数栈的协同“表演”为了让你更直观地感受这两个结构的运作过程我来模拟一段简单代码的执行public int calc(int a, int b) { int c a b; return c; }这段代码对应的字节码大致是这样的iload_1 // 将局部变量表中索引为1的int变量(a)压入操作数栈 iload_2 // 将局部变量表中索引为2的int变量(b)压入操作数栈 iadd // 弹出栈顶两个int相加把结果压回操作数栈 istore_3 // 将操作数栈栈顶的int保存到局部变量表中索引为3的变量(c) iload_3 // 将局部变量表中索引为3的int变量(c)压入操作数栈 ireturn // 返回操作数栈栈顶的int为什么局部变量表索引从1开始而不是0因为实例方法非static方法的局部变量表槽位0固定存放this引用。静态方法则没有这个问题。这个细节面试时偶尔会问到记下来没坏处。操作数栈这种“工作台”模式的优点在于字节码指令不需要指定操作数的内存地址只需要和栈顶交互这种设计让指令更加紧凑也更容易在不同平台上解释执行。3.3 栈的大小异常StackOverflowError与OutOfMemoryError每个线程的虚拟机栈容量是有限的可以用-Xss参数指定。默认值跟平台有关Linux x64下通常是1MB。当方法调用深度超过栈容量时会抛出StackOverflowError。经典的递归没有终止条件就会触发这个错误比如public void infiniteLoop() { while (true) { infiniteLoop(); } }如果你的递归逻辑本身没问题但还是栈溢出了说明方法调用层级太深。可以通过适当调大-Xss缓解比如-Xss2m但这只是治标。更合理的做法是检查递归是否可以改成迭代或者把“栈深度大”的数据结构改成堆结构比如把递归改成显式栈遍历。还有一种情况是创建线程时栈空间分配失败抛出OutOfMemoryError: unable to create new native thread。这个报错的根因通常是线程数太多或者每个线程栈太大导致操作系统层面的内存不够。你可能会问线程栈空间不是JVM在管理吗其实线程的创建需要向操作系统申请内存来承载栈帧结构所以当进程的内存配额耗尽、或者操作系统线程数受限比如ulimit -u限制时就会触发这个OOM。遇到这种问题我的处理顺序是先看代码里有没有线程泄露比如线程池没关闭再看-Xss和-Xmx的配比是否合理最后确认操作系统的线程数限制。这里有个实际操作中的经验高并发Web应用的线程数是“线程池 业务线程”的总和每个线程都会占用一块栈内存。假设-Xss1m2000个线程就差不多要2GB的虚拟内存这还没算堆和其他区域。所以设置线程池大小时不能只盯着CPU核心数还要把栈内存成本算进去。3.4 本地方法栈容易被忽略的“第二栈区”本地方法栈Native Method Stack是为虚拟机执行native方法服务的。所谓native方法就是那种用native关键字修饰、由非Java语言通常是C/C实现的方法。在HotSpot虚拟机实现里本地方法栈和虚拟机栈是合二为一的所以你在jstack里看到线程栈往往同时包含Java栈帧和native栈帧。这个区域虽然讨论得少但在排查一类问题时会用到通过JNI调用底层库导致的内存占用过高或者native线程崩溃出现SIGSEGV。当你看到这类问题却排查不到Java层异常时就要怀疑是不是本地方法栈或者JNI层出现了问题。4. 方法区、程序计数器两个“低存在感”但必须理解的部分4.1 方法区的前世今生从永久代到元空间方法区用来存储类元信息、运行时常量池、静态变量、JIT编译后的代码等数据。逻辑上它是堆的一个逻辑部分但在HotSpot的实现里它被独立出来了。这里有个非常重要的演进历史JDK 7及以前方法区在HotSpot中被称为永久代Permanent GenerationJDK 8开始永久代被移除方法区的落地实现换成了元空间Metaspace。这个变化有一个直接后果——元空间不再占用JVM堆内存而是使用本地内存Native Memory且默认情况下大小没有上限。这个设计变更带来的实际影响很多人直到踩坑才意识到因为元空间默认不设上限如果类加载器没有回收、或者有大量动态生成类的场景比如频繁使用CGLIB、反射生成代理类元空间就会不断膨胀直到操作系统内存被耗尽最终抛出OutOfMemoryError: Metaspace。处理这个问题的思路有两个方向一是合理设置上限比如-XX:MaxMetaspaceSize512m至少让JVM在达到上限时报出明确错误而不是拖垮整台机器二是排查类加载器泄漏。大多数时候问题的根源是重复创建类加载器且没有释放对类和类加载器的引用导致元空间的元数据无法卸载。顺带说一句虽然元空间使用本地内存但-Xmx的堆内存并不包含它。所以你在做容器内存配额时如果设置的堆大小接近容器内存上限而又开启了大量动态代理极有可能由于元空间占用未统计而被操作系统“杀死”。我在给容器设置内存上限时一般会让堆的最大值加上元空间上限后再保留10%~20%的余量。4.2 运行时常量池方法区里的“静态信息仓库”运行时常量池是方法区的一部分存放编译期生成的各种字面量比如字符串值、final常量值和符号引用类、方法、字段的名称和描述符。Class文件中的常量池内容会在类加载后进入运行时常量池。很多人面试被问到的“字符串常量池”和运行时常量池是什么关系这里要理清运行时常量池是方法区里的大概念字符串常量池是它的重要组成部分。具体理一理字符串字面量比如hello在类加载时会被放入方法区的字符串常量池String.intern()方法可以动态把一个字符串对象放入字符串常量池如果池中已有相同内容的字符串则返回池中引用JDK 7之后字符串常量池被移到了堆中也就是不再占用永久代。这导致了一个现象可以通过大量intern()调用增加堆内存占用制造堆OOM——这个在排查问题时会遇到。4.3 程序计数器唯一不会OOM的区域程序计数器Program Counter Register是所有区域里最“小”的它保存的是当前线程正在执行的字节码指令地址。如果是执行native方法程序计数器的值为空Undefined。为什么它是线程私有的因为每个线程都在执行不同的指令流CPU在多线程切换时需要恢复每个线程的“执行到哪一步了”这个恢复依据就是程序计数器。它也是唯一一个在Java虚拟机规范中不规定任何OutOfMemoryError情况的区域——因为它的容量天然就是足够小的、固定的不存在动态扩展的场景。4.4 对象的一生把五个区域串成一条故事线看到这里如果你已经理解了每个区域的职责那我们就把这五个区域串起来模拟一个对象从创建到回收的完整旅程。这很有助于建立全局感你写了一个UserService类方法里调用User user new User()类加载阶段UserService和User的类元信息被加载进方法区元空间常量池中的符号引用被解析为直接引用JVM创建线程时虚拟机栈分配好栈内存程序计数器记录方法正在执行的字节码位置执行new User()时JVM在Eden区TLAB优先分配一块内存给User对象对象的类型指针指向方法区的User类元信息实例数据比如name、age字段存储在对象体内方法内部调用其他方法时新的栈帧压入虚拟机栈局部变量表和操作数栈协同工作完成运算经过多次Minor GCUser对象幸存下来从Survivor区往老年代移动最终到达老年代对象不再被任何GC Roots引用时它变成“垃圾”等待GC回收其占据的堆内存被回收对象生命结束。这条故事线其实涵盖了类加载、JVM内存分布、GC回收机制三个主题——如果你能把这个链条讲清楚JVM内存模型这块的知识就真正串起来了。5. 内存参数与调优思路给JVM“分配预算”5.1 核心内存参数速查表JVM参数是“讲给JVM听的配置”内存相关的参数尤其重要。我先给你一份使用频率最高的速查表参数作用默认值HotSpot备注-Xms初始堆大小物理内存的1/64与-Xmx相同可避免扩容抖动-Xmx最大堆大小物理内存的1/4大对象多的服务可以适当调大-Xmn新生代大小堆的约1/3需要结合GC日志调整-Xss每个线程栈大小1MBLinux x64高线程数场景不宜设过大-XX:MaxMetaspaceSize元空间上限无上限动态代理多的场景建议设上限-XX:SurvivorRatioEden与Survivor的比例8默认是8:1:1-XX:MaxTenuringThreshold晋升老年代的年龄阈值15CMS收集器会动态调整-XX:PretenureSizeThreshold大对象直接进入老年代的阈值0无限只对Serial和ParNew有效-XX:NewRatio老年代与新生代的比值2老年代 新生代 × 25.2 参数之间是“联动”的别单独拍脑袋JVM内存参数不是一个个孤立地调它们之间互相影响。举几个实际案例案例一堆总量没变只调大新生代。假设-Xmx2g不变-Xmn从500m调到1.5g。表面上新生代大了GC频率低了但老年代被压缩到只剩几百MB。一旦老年代里对象存储超过预留空间Full GC触发频率反而飙升。最终整条链路更卡。案例二线程栈设置过大。-Xss2m本身没问题但如果线程池核心线程数上千这2000m的虚拟内存开销就会变成实实在在的资源压力。高并发网关服务里-Xss256k到-Xss512k往往是更舒服的区间。案例三元空间上限设得太低。你在本地开发一天都没事儿打包上线后每次部署都报OutOfMemoryError: Metaspace。查日志发现业务框架启动了大量动态代理跑几分钟就把128m的元空间塞满了。这个问题的解法是结合实际情况调高上限同时优化类加载器的复用。5.3 如何用JVM参数搭配出“一套能打的配置”根据我个人实践一个典型的Spring Boot服务4核8G容器可以按下面这个思路配置java -Xms4g -Xmx4g \ -Xmn1536m \ -Xss512k \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -jar app.jar给几个解释-Xms4g -Xmx4g固定堆容量启动时就申请好避免运行时扩容造成额外开销-Xmn1536m新生代1.5g约占堆的37.5%对大部分业务足够了-Xss512k单线程栈512k在业务线程较多时节省内存-XX:MaxMetaspaceSize512m给元空间设个护栏防止类加载器泄漏拖垮宿主机-XX:UseG1GCJDK 8u40开始常用的低延迟收集器适合多核大内存场景-XX:MaxGCPauseMillis200设定GC暂停目标G1会调整回收行为来尽量满足这个期望。这个配置不是“标准答案”而是一个相对稳妥的起点。真实环境里一定要结合GC日志、压测数据、业务类型进行迭代调整。你可以在IDEA的启动配置里直接把VM options加上测试本地模拟高内存场景时也方便观察顺便解决开发测试时出现的OOM问题。5.4 线程池与内存的“隐藏关系”JVM内存模型中每个线程都有自己的虚拟机栈这个设计在“线程池设置最大线程数”这个问题上显得尤为重要。网上很多文章会说“线程池最大线程数 CPU核心数 1”或者“2倍核心数”但很少提到内存维度的约束。我的观点是线程池最大线程数要先看内存能不能撑住再看CPU用不用得满。假设单线程栈是1m一个业务线程池多出500个线程额外栈内存就占了500m。如果你的堆已经占了4g机器一共8g这500m就会踩到系统物理内存红线。实际操作中我会先估算一个基础内存预算堆比如4g 元空间上限512m 线程数比如1000线程 × 512k栈 堆外缓存/网络缓冲区。算完以后再决定线程池参数这样出来的配置才是有根的。6. 常见内存问题排查从现象到原因的思维范式6.1 五种OOM类型速查与定位方向报错信息对应区域初步定位方向Java heap space堆对象堆积、大对象分配、内存泄漏GC overhead limit exceeded堆GC回收效果极差98%时间在GC回收不到2%空间Metaspace方法区动态生成类过多、类加载器未回收Direct buffer memory堆外内存NIO的DirectByteBuffer分配过多未释放unable to create new native thread栈操作系统层线程数超限、栈空间无法申请6.2 排查工具用jps、jstat、jmap、jstack、Arthas快速定位很多新手拿到线上的OOM日志会慌其实排查链路是固定的按顺序走就行jps先确认目标Java进程的PID。jstat -gcutil PID 1000观察GC压力。如果FGC次数飙升、FGC时间很长堆内存大概率已经吃紧。jmap -dump:live,formatb,fileheap.hprof PID在内存快照导出前通常建议先触发一次Full GC通过-dump:live参数获取存活对象堆转储文件会小很多。用MAT或JProfiler分析堆转储文件重点看大对象和持有引用最多的对象。jstack PID thread.dumpdump线程栈查看线程数量和线程状态排查是否线程阻塞导致对象堆积。Arthas线上排查的神器dashboard看堆内存和非堆内存的实时变化heapdump直接导出堆thread查看线程状态sc/sm查类加载情况非常契合Arthas这类工具的典型使用场景。6.3 实战案例一次“GC overhead limit exceeded”的定位过程有一个比较典型的案例某服务上线后运行三天开始频繁抛出GC overhead limit exceeded堆内存充足期仅为启动后的前半天。排查过程大概是这样第一步看GC日志。jstat发现Eden区每秒钟Minor GC一次而且每次GC后存活对象大量晋升到老年代老年代空间在半天内从20%涨到95%。第二步导出堆转储。用MAT分析后发现有个ConcurrentHashMap占用了堆内存的80%以上其中key是一个自定义对象。继续追查发现代码里把“订单流水号”作为key写入缓存但value是订单的全部明细且这个Map是静态的、永远不清理。数据一多就把堆塞满了。第三步修复。改法很简单给缓存加上容量上限使用Caffeine/LRU替换掉无界Map同时核查为什么老年代晋升这么快——发现Survivor空间设太小8:1:1的默认比例在“高对象创建速率”场景下不够用把-XX:SurvivorRatio从8调成16后晋升量显著下降。这个案例看起来很简单但它体现了一个很经典的排查路径先看GC频率 → 再导dump → 找大对象 → 修代码 调参数。没有内存模型的知识你可能根本想不到要去看GC日志里的晋升情况更不会理解Survivor空间为什么会成为瓶颈。我在实际排查中还发现很多人会忽略一种隐蔽的泄漏ThreadLocal的使用不清理。ThreadLocal的值被放在线程的ThreadLocalMap里而线程又长期存活在线程池中如果每次请求都往ThreadLocal里塞数据而不调用remove那么这些数据会一直占着内存最终表现为老年代持续缓慢增长、FGC次数越来越多、响应越来越慢。这类问题用jmap看不出特别明显的大对象但用jstat观察老年代曲线就能看出来——它就是一条平缓但持续向上的斜线。最后再说两句实在话学JVM内存模型不要把它当八股文去背。我自己的感受是每经历过一次线上内存事故你对这块知识的理解就会深一层。如果你现在还没遇到类似问题强烈建议你自己搭一个“内存故障演练”——写个程序故意制造堆OOM、栈溢出、元空间膨胀再用jmap、jstat、jstack一路排查下来。这个过程走完比读十篇博客都管用。另外一个值得记住的小技巧配置JVM参数时永远留出余量。无论是本机IDEA开发时设置的堆内存大小还是生产环境的容器配额都不要卡着临界点配置。留得10%缓冲关键时刻能救你一命。希望这篇文章能给你铺一条相对完整的理解路径后面再回过头来看各种GC日志和OOM报错时你不会只觉得它们是一堆恐怖的乱码。