1. 面试被问“两者区别”时的第一反应和实际答案差在哪儿有段时间我经常被同一个问题卡住面试官先问“说说JVM运行时数据区”又问“说说Java内存模型”。当时我的第一反应是“这俩不是一个东西吗”——都是在讲内存都是JVM相关名称里都有“内存”两个字。但随着项目里真正排查过几次OOM和并发问题我才发现把这两者画等号是会出事的它们一个是“房子怎么分区”另一个是“房间里住的人怎么沟通”压根不在同一个维度。这篇文章想把这两个核心概念彻底讲明白先拆JVM运行时数据区也叫内存区域或内存结构这是JVM规范里定义的内存分区再讲Java内存模型Java Memory ModelJMM这是多线程并发下定义共享变量读写规则的抽象模型。我会结合自己在实际项目里排查内存溢出、处理并发Bug的经验把你面试时最容易被追问的几个点以及日常开发里最容易踩的误区一次性理清楚。1.1 为什么“内存模型”这四个字特别容易造成误会先说个背景。早期Java规范里JVM内存相关的描述其实比较零散。后来JSR-133Java Specification Request 133对Java内存模型做了重定义并引入了volatile和synchronized等关键字相关的语义保证最终在JDK 5发布时成型。这套“Java内存模型”专门解决多线程环境下共享数据的可见性、原子性和有序性问题。而“运行时数据区”同样出自JVM规范描述的是JVM启动后内存划分为哪几块、各自存放什么数据、生命周期如何、抛什么异常。这两份规范讲的是不同的事情但翻译成中文后都带了“内存”两个字于是初学者经常把它们归为一类。用生活化的类比来理解运行时数据区是装修图纸里每个房间的功能分区——厨房、卧室、客厅各在哪儿面积多大谁住在哪个房间JMM则是住在同一套房子里不同人之间的沟通规则——厨房里产生的消息怎么传递给卧室里的人什么时候必须用对讲机volatile什么时候可以靠墙上贴条普通变量什么时候必须面对面开会synchronized。1.2 运行时数据区回答的是“对象存在哪儿”从JVM规范角度来看运行时数据区是一块静态划分的内存蓝图包括程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区以及直接内存虽然规范里严格说直接内存不属于运行时数据区但实际使用中绕不开它。它回答的问题是一个线程被创建后它的栈帧放哪儿new出来的对象放哪儿类信息、常量、静态变量放哪儿这些区域的划分在JVM启动后就基本确定了JVM参数比如-Xmx、-Xss、-XX:MaxMetaspaceSize控制的就是这些区域的容量上限。1.3 JMM回答的是“一个线程看到的值是不是最新的”JMM不关心对象放哪块内存区域它关心的是线程A修改了一个共享变量线程B什么时候能看到这个修改编译器、CPU、缓存导致的重排序哪些情况下可以被接受哪些情况下必须禁止它定义了一套抽象规则每个线程有自己的工作内存共享变量存在于主内存线程对变量的读写必须通过工作内存中转。所以下次再有人问你“运行时数据区和JMM的差别”你可以用一句话概括运行时数据区描述JVM内存的分区结构JMM描述多线程并发读写共享变量的规则。前者是数据结构问题后者是并发协议问题。2. 运行时数据区的六块地皮每一块的职责、容灾与坑2.1 程序计数器唯一不会OutOfMemoryError的区域程序计数器Program Counter Register是运行时数据区里最小的一块用来记录当前线程正在执行的字节码指令地址。每个线程独立拥有一个互不共享。为什么它不会OOM因为它的容量只够存一个字节码行号或Native方法标记JVM规范没有给它定义任何OutOfMemoryError场景。实际开发中我几乎不会去调它但会在理解“线程上下文切换”时想到它一个线程被换出CPU后再次回到运行状态靠的就是程序计数器记住的“上次执行到哪一行”。注意如果执行的是Native方法程序计数器的值是Undefined因为不是字节码指令不需要记录行号。2.2 Java虚拟机栈栈帧里藏着局部变量表、操作数栈和动态链接Java虚拟机栈是线程私有的生命周期和线程相同。每执行一个方法就会创建一个栈帧栈帧里面有几个关键部分组成局部变量表存放基本数据类型、引用类型变量。注意long和double占2个Slot其他类型占1个Slot。操作数栈字节码指令运算时用于临时存放数据的“工作台”。动态链接指向运行时常量池中该方法的引用。支持多态调用时的方法解析。方法出口正常返回或异常抛出时的返回地址信息。虚拟机会在这块区域抛出两种异常线程请求的栈深度大于虚拟机允许的深度时抛StackOverflowError如果栈容量允许动态扩展但内存不足时抛OutOfMemoryError。这里有个实际经验无限递归是触发StackOverflowError最快的方式但这反而不可怕更麻烦的是在长时间运行的服务里线程数量不受控地增加最终栈内存总和耗尽导致OOM。遇到后一种情况通常得靠线程转储Thread Dump找出线程堆积的原因。2.3 本地方法栈给Native方法用的地盘Java虚拟机栈管Java方法执行本地方法栈则是为Native方法服务。HotSpot虚拟机直接把它和Java虚拟机栈合并了所以用JVM参数-Xss调整的其实是两者合并后的栈大小。日常排查时不用单独区分但面试时知道“HotSpot合并了这两者”是个加分项。2.4 Java堆所有线程共享的对象分配仓库Java堆是运行时数据区里最大的一块也是GC垃圾收集的核心战场。几乎所有对象实例和数组都在这里分配经过逃逸分析后栈上分配的情况除外后面我会专门讲这个例外。堆在物理上被分为新生代和老年代新生代又细分为Eden区、From Survivor区、To Survivor区默认比例约为8:1:1但可以通过-XX:SurvivorRatio调整。老年代存放长期存活或大对象。大多数对象在Eden区分配Minor GC后存活对象进入Survivor区经过一定次数的年龄递增后进入老年代大对象比如超过-XX:PretenureSizeThreshold的对象直接进入老年代。实际排查中我见到的OOM大多发生在堆上。常见原因包括内存泄漏对象被无意识持有、一次性加载大量数据、循环创建对象未释放引用。需要关注的JVM参数有-Xms初始堆、-Xmx最大堆、-Xmn新生代大小、-XX:MaxDirectMemorySize直接内存上限严格说不算堆但容易混淆。2.5 方法区与运行时常量池从永久代到元空间的变迁方法区存放类元信息、运行时常量池、静态变量、JIT编译后的代码等。在HotSpot虚拟机历史上方法区在JDK 7及以前用永久代PermGen实现当时如果加载的类太多会抛“java.lang.OutOfMemoryError: PermGen space”JDK 8之后改为元空间Metaspace并使用本地内存实现默认不再受限于JVM堆内存大小。运行时常量池是方法区的一部分存类文件常量池中的各种字面量和符号引用。String.intern()方法就和它有关——把字符串放入常量池时可以复用对象。JDK 7之后字符串常量池从永久代移到了堆中这也导致了一些字符串驻留和GC交互上的变化。一个容易踩坑的点元空间虽然用本地内存但不代表无限。容器环境下如果整个进程内存被限制元空间膨胀照样会把进程挤爆。所以线上环境我通常会设置-XX:MaxMetaspaceSize宁可频繁触发Full GC也不要让进程因本地内存耗尽被操作系统杀死。2.6 直接内存NIO和Netty性能的关键但不在堆内直接内存不是运行时数据区的正式成员但在JDK 4引入NIO后它变得不可或缺。它的特点是通过DirectByteBuffer分配不受Java堆大小限制受机器物理内存和-XX:MaxDirectMemorySize约束。为什么Netty和Kafka这类高性能框架偏爱直接内存因为当数据需要从磁盘或网络读写时使用直接内存可以避免一次“堆内内存 → 堆外内存”的数据拷贝直接进行I/O操作。代价是堆外内存的管理和回收不像堆内GC那么方便容易造成物理内存泄漏。实际经验如果项目用了Netty线上监控观察“进程RSS常驻内存持续增长但堆内存占用正常”大概率是直接内存泄漏。此时要看是否有DirectByteBuffer没有释放以及Netty的PooledByteBufAllocator配置是否合理。3. JMM的规则体系主内存、工作内存、原子操作与happens-before3.1 主内存和工作内存并不是堆和虚拟机栈的另一个叫法这是JMM里最容易混淆的一个地方。有人觉得“主内存就是堆工作内存就是虚拟机栈”这是不对的。JMM的主内存和工作内存是一个抽象概念它描述的是共享变量在线程间可见性的逻辑层级而堆和虚拟机栈是JVM内存区域的物理划分两者层次不同。在JMM的模型里所有共享变量存在主内存每个线程有自己的工作内存。线程对变量的所有操作读、写都必须在工作内存中完成不能直接操作主内存变量不同线程之间不能直接访问对方的工作内存线程间变量值的传递必须通过主内存完成。用两个人传纸条来类比主内存是公共告示板工作内存是各自的小本本。A在小本本上记了一个值必须把这张纸条贴到公共告示板上B才可能看到如果A一直不贴B永远不知道A记了什么。volatile就是强制“写完必须立刻贴到告示板上读的时候必须重新看告示板”的规则。3.2 八种原子操作从read到store看一个变量怎么跨线程流动JMM定义了八种原子操作来保证内存交互的可靠性lock把一个变量标记为线程独占状态。unlock把锁定状态的变量释放出来。read把一个主内存变量的值传输到线程的工作内存。load把read操作传来的值放入工作内存变量副本中。use把工作内存中的值传给执行引擎。assign把执行引擎计算得到的新值赋值给工作内存变量。store把工作内存变量的值传送回主内存。write把store操作传来的值写入主内存变量中。一条完整的写入链路是assign → store → write一条完整的读取链路是read → load → use。这些操作本身是原子的但组合起来不一定满足可见性和有序性所以还需要volatile和锁这样的高层同步机制兜底。3.3 volatile的可见性与有序性它的权利边界在哪儿volatile可以说是JMM规则最直接的实践产物。它有两个核心保证可见性写入volatile变量后JMM会立即将工作内存中的值刷新到主内存读取volatile变量时会强制从主内存重新加载。有序性volatile变量读写会插入内存屏障Memory Barrier禁止指令重排序跨越屏障。但很多人以为volatile也保证原子性这是误解。典型的反例是volatile int count上的count这个操作包含读取、加1、写回三个步骤不是原子性的。两个线程同时执行时仍然可能丢失更新。要保证原子性得用AtomicInteger、synchronized或者LongAdder。关于内存屏障的底层实现值得一提在x86体系下写volatile变量会触发StoreStore屏障和StoreLoad屏障读volatile变量会触发LoadLoad屏障和LoadStore屏障。这些屏障的作用是禁止CPU和编译器越过屏障乱序执行。面试时如果被深挖能说出屏障类型和插入位置会是很强的加分项。3.4 happens-before原则不需要锁也能保证顺序的规则集JMM用happens-before原则来界定“如果A happens-before B那么A的执行结果对B可见”。它是判断两个操作是否真的存在先后顺序的规则即使没有同步关键字也能依赖这些天然规则程序次序规则在一个线程内书写在前面的操作happens-before书写在后面的操作。监视器锁规则解锁操作happens-before后续对同一把锁的加锁操作。volatile变量规则对一个volatile变量的写操作happens-before后续对这个变量的读操作。传递性如果A happens-before BB happens-before C那么A happens-before C。线程启动规则Thread.start() happens-before被启动线程中的任何操作。线程终止规则线程中的所有操作happens-before其他线程检测到该线程终止比如Thread.join()返回。线程中断规则对线程的中断操作happens-before被中断线程检测到中断事件比如抛出InterruptedException。对象终结规则一个对象初始化完成happens-before它的finalize()方法调用。实际项目里happens-before最常用的场景就是安全发布对象通过volatile修饰引用确保对象构造函数中的赋值操作对另一个线程可见。4. 从线上故障反推概念三个真实问题的心路历程4.1 一次堆内存OOM排查jmap与MAT立功了某项目在压测阶段接口突然变慢随后整个应用频繁Full GC最后抛“java.lang.OutOfMemoryError: Java heap space”。我当时的排查链路是这样用jmap -heap查看堆配置和当前各区使用情况发现老年代几乎占满新生代GC后存活对象大量进入老年代。用jmap -dump:formatb,fileheap.hprof生成堆转储文件导入MATMemory Analyzer Tool分析。MAT的Dominator Tree显示有个缓存对象占据了约70%的堆空间。进一步查看引用链发现是项目中一个静态Map没有做容量控制业务请求不断往里塞数据从不清理。修复方式很简单改用带过期策略的本地缓存比如Caffeine并限制最大条数。复盘时我重新理解了“堆是共享的”意味着什么静态集合本质上就是一个全局的GC Root只要它不变空里面的对象永远不会被回收。这也提醒我凡是往全局集合里放数据都得先回答一个问题这个数据什么时候被移除4.2 栈内存过小导致的诡异故障递归并非唯一元凶另一个案例是某服务运行一段时间后线程突然大量报StackOverflowError。起初以为是某个递归方法死循环但翻代码发现递归深度并不大。后来用jstack抓线程转储发现大量线程阻塞在一个网络调用的等待逻辑上而这个调用内部使用了嵌套同步块导致线程持有锁不放。锁竞争加剧后线程等待期间又不断有新的任务被提交到线程池线程栈内存无限累积最终栈深度超过-Xss设置值。排查完成后我意识到虚拟机和操作系统是两套资源体系线程的栈内存不在堆内不能用堆的监控覆盖栈的监控。线上环境应该对每个容器的线程数做实时监控必要时用-XX:ThreadStackSize合理调整或设置线程池上限。4.3 并发计数Bug复现volatile为什么救不了count复现环境很简单两个线程同时对同一个volatile变量执行100万次自增最终结果远小于200万。我带着团队做了一次现场演示用javap -c查看字节码发现count被拆成了四条字节码指令getstatic count iconst_1 iadd putstatic count在线程切换的间隙两个线程可能同时读到同一个count值分别加1后写回等于只加了一次。这个案例比任何理论解释都能说服人可见性解决的是“读到的旧值”问题原子性解决的是“一旦读出来、加完、写回这三个步骤被拆开”的问题。最终方案是改用LongAdder因为它内部把热点拆成了多个Cell并发下分散竞争再通过sum()汇总结果既保证最终一致性又能避免单一原子变量带来的CAS竞争。4.4 元空间需要被监控类加载器泄漏没有想象中那么少还有一个案例和动态代理有关。某项目用CGLIB频繁生成代理类同时自定义类加载器没有正确回收导致每次生成新代理类都往元空间塞入新的类元数据。上线几天后元空间占用持续上升最终进程被操作系统OOMKiller杀掉。这个故障的排查相对曲折常规的堆转储分析看不到元空间内部因为类元数据不占Java堆。后来通过JMX监控java.lang.management.MemoryMXBean里的NonHeapMemoryUsage再配合-verbose:class观察实际加载的类名规律才定位到动态代理类数量异常。修复方式是限制类加载器的数量、复用已有的代理类对象并在容器层面设置-XX:MaxMetaspaceSize作为兜底。这个案例让我正视了一个事实JVM的每一块内存区域都值得单独监控只盯着堆内存远远不够。5. 实战中的五个常见认知误区与排查思路5.1 误区一以为“对象只在堆上分配”严格来说经过逃逸分析确认对象不会被外部访问HotSpot会把对象直接分配到线程栈上方法结束后栈帧弹出即回收无需GC介入。这种优化叫栈上分配Stack Allocation利用的是标量替换技术——把一个对象拆成若干个基本类型变量。JVM参数-server -XX:DoEscapeAnalysis -XX:EliminateAllocations在JDK 8默认为开启状态。如果你的代码里有只在线程内部使用的小对象就不必担心GC压力。但要注意一旦对象被方法返回、存入静态字段或逃逸到其他线程栈上分配自动失效。5.2 误区二以为“volatile保证线程安全”这是个老生常谈的认知偏差。volatile保证的是可见性和有序性不保证复合操作的原子性。判断一个变量是否适合用volatile可以问三个问题这个变量的值会被多个线程同时修改吗如果会且修改不是原子操作volatile不够。这个变量作为状态标志只要保证一个线程改了另一个线程立刻看到volatile足够。是否有依赖当前值的操作如自增、先判断再赋值有就不够。实际开发中volatile最常见的安全用例就是“状态开关”比如private volatile boolean running true;另一个线程通过判断running来控制循环退出。5.3 误区三把“主内存”直接对应到“堆内存”上文已经强调过JMM主内存是一个抽象概念。线程的工作内存对应到物理层面可能是CPU的寄存器、L1/L2缓存也可能一部分是堆内存取决于JVM实现。所以不要试图用jstat或者jmap去“查看”JMM的主内存它是逻辑模型不是可观测内存块。这种抽象的最大价值在于它告诉程序员不需要关心CPU缓存一致性协议、不需要关心具体处理器架构只要按照Java内存模型编写并发代码就能获得跨平台的内存可见性保证。5.4 误区四忽略安全点SafePoint对GC和线程转储的影响GC触发时线程必须在安全点停顿这个机制虽然不属于JMM的正式内容但实际观察线程状态时需要理解。jstack中的“vm_thread”或“running”状态有时候并不代表线程真的在干活而是在等待进入安全点。排查响应缓慢问题时如果发现GC日志显示安全点停顿时间过长同时大量线程处于可运行但实际未推进的状态说明STWStop-The-World过长需要考虑降低GC频率或改用低延迟垃圾收集器。5.5 误区五把“内存溢出”和“内存泄漏”混为一谈内存溢出Memory Overflow是分配不出内存时抛出的异常内存泄漏Memory Leak是对象该回收但没有被回收持续占用内存。泄漏往往是溢出的前因但有些溢出并不伴随泄漏——比如一次性加载超大文件修改代码、限制单批数据量即可解决。排查内存泄漏除了堆转储分析还要关注GC日志中“老年代使用率是否持续上升”以及通过VisualVM/JConsole观察内存使用曲线。如果使用率每轮GC后降不下来基本可以判定有对象被长期引用。6. 写在最后的排查清单高性能并发服务的两个必备视角我在实际项目中养成了一个习惯遇到内存或并发问题先确定自己站在哪个“坐标系”里。如果是对象太多、堆不够用切到运行时数据区的视图如果是数据改了别人看不见、指令被重排切到JMM的视图。两个视角分开看问题往往比混在一起排查更高效。最后分享一份实用的自查清单先看堆内存曲线和GC日志判断是内存泄漏还是内存溢出这决定后面走哪条路。再用jstack看线程状态有没有大量BLOCKED、WAITING或死锁尤其是等待GC安全点的线程。如果存在并发可见性问题优先检查共享变量是否被volatile修饰复合操作是否加了锁。每块独立内存区域都必须有监控堆、元空间、直接内存、线程栈缺哪个都可能出大事。线上服务建议至少设置-Xmx、-XX:MaxMetaspaceSize、-XX:MaxDirectMemorySize三个上限避免进程级失控。JVM运行时数据区和Java内存模型一个管空间一个管规则。把它们的差别刻在脑子里面试时能讲得清楚出问题时能快速定位方向——这两件事是同一件事的两面。 
长河君 · 2026/10/15 7:28:56 · 阅读 1.2k JVM运行时数据区与Java内存模型：从内存分区到并发规则
1. 面试被问“两者区别”时的第一反应和实际答案差在哪儿有段时间我经常被同一个问题卡住面试官先问“说说JVM运行时数据区”又问“说说Java内存模型”。当时我的第一反应是“这俩不是一个东西吗”——都是在讲内存都是JVM相关名称里都有“内存”两个字。但随着项目里真正排查过几次OOM和并发问题我才发现把这两者画等号是会出事的它们一个是“房子怎么分区”另一个是“房间里住的人怎么沟通”压根不在同一个维度。这篇文章想把这两个核心概念彻底讲明白先拆JVM运行时数据区也叫内存区域或内存结构这是JVM规范里定义的内存分区再讲Java内存模型Java Memory ModelJMM这是多线程并发下定义共享变量读写规则的抽象模型。我会结合自己在实际项目里排查内存溢出、处理并发Bug的经验把你面试时最容易被追问的几个点以及日常开发里最容易踩的误区一次性理清楚。1.1 为什么“内存模型”这四个字特别容易造成误会先说个背景。早期Java规范里JVM内存相关的描述其实比较零散。后来JSR-133Java Specification Request 133对Java内存模型做了重定义并引入了volatile和synchronized等关键字相关的语义保证最终在JDK 5发布时成型。这套“Java内存模型”专门解决多线程环境下共享数据的可见性、原子性和有序性问题。而“运行时数据区”同样出自JVM规范描述的是JVM启动后内存划分为哪几块、各自存放什么数据、生命周期如何、抛什么异常。这两份规范讲的是不同的事情但翻译成中文后都带了“内存”两个字于是初学者经常把它们归为一类。用生活化的类比来理解运行时数据区是装修图纸里每个房间的功能分区——厨房、卧室、客厅各在哪儿面积多大谁住在哪个房间JMM则是住在同一套房子里不同人之间的沟通规则——厨房里产生的消息怎么传递给卧室里的人什么时候必须用对讲机volatile什么时候可以靠墙上贴条普通变量什么时候必须面对面开会synchronized。1.2 运行时数据区回答的是“对象存在哪儿”从JVM规范角度来看运行时数据区是一块静态划分的内存蓝图包括程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区以及直接内存虽然规范里严格说直接内存不属于运行时数据区但实际使用中绕不开它。它回答的问题是一个线程被创建后它的栈帧放哪儿new出来的对象放哪儿类信息、常量、静态变量放哪儿这些区域的划分在JVM启动后就基本确定了JVM参数比如-Xmx、-Xss、-XX:MaxMetaspaceSize控制的就是这些区域的容量上限。1.3 JMM回答的是“一个线程看到的值是不是最新的”JMM不关心对象放哪块内存区域它关心的是线程A修改了一个共享变量线程B什么时候能看到这个修改编译器、CPU、缓存导致的重排序哪些情况下可以被接受哪些情况下必须禁止它定义了一套抽象规则每个线程有自己的工作内存共享变量存在于主内存线程对变量的读写必须通过工作内存中转。所以下次再有人问你“运行时数据区和JMM的差别”你可以用一句话概括运行时数据区描述JVM内存的分区结构JMM描述多线程并发读写共享变量的规则。前者是数据结构问题后者是并发协议问题。2. 运行时数据区的六块地皮每一块的职责、容灾与坑2.1 程序计数器唯一不会OutOfMemoryError的区域程序计数器Program Counter Register是运行时数据区里最小的一块用来记录当前线程正在执行的字节码指令地址。每个线程独立拥有一个互不共享。为什么它不会OOM因为它的容量只够存一个字节码行号或Native方法标记JVM规范没有给它定义任何OutOfMemoryError场景。实际开发中我几乎不会去调它但会在理解“线程上下文切换”时想到它一个线程被换出CPU后再次回到运行状态靠的就是程序计数器记住的“上次执行到哪一行”。注意如果执行的是Native方法程序计数器的值是Undefined因为不是字节码指令不需要记录行号。2.2 Java虚拟机栈栈帧里藏着局部变量表、操作数栈和动态链接Java虚拟机栈是线程私有的生命周期和线程相同。每执行一个方法就会创建一个栈帧栈帧里面有几个关键部分组成局部变量表存放基本数据类型、引用类型变量。注意long和double占2个Slot其他类型占1个Slot。操作数栈字节码指令运算时用于临时存放数据的“工作台”。动态链接指向运行时常量池中该方法的引用。支持多态调用时的方法解析。方法出口正常返回或异常抛出时的返回地址信息。虚拟机会在这块区域抛出两种异常线程请求的栈深度大于虚拟机允许的深度时抛StackOverflowError如果栈容量允许动态扩展但内存不足时抛OutOfMemoryError。这里有个实际经验无限递归是触发StackOverflowError最快的方式但这反而不可怕更麻烦的是在长时间运行的服务里线程数量不受控地增加最终栈内存总和耗尽导致OOM。遇到后一种情况通常得靠线程转储Thread Dump找出线程堆积的原因。2.3 本地方法栈给Native方法用的地盘Java虚拟机栈管Java方法执行本地方法栈则是为Native方法服务。HotSpot虚拟机直接把它和Java虚拟机栈合并了所以用JVM参数-Xss调整的其实是两者合并后的栈大小。日常排查时不用单独区分但面试时知道“HotSpot合并了这两者”是个加分项。2.4 Java堆所有线程共享的对象分配仓库Java堆是运行时数据区里最大的一块也是GC垃圾收集的核心战场。几乎所有对象实例和数组都在这里分配经过逃逸分析后栈上分配的情况除外后面我会专门讲这个例外。堆在物理上被分为新生代和老年代新生代又细分为Eden区、From Survivor区、To Survivor区默认比例约为8:1:1但可以通过-XX:SurvivorRatio调整。老年代存放长期存活或大对象。大多数对象在Eden区分配Minor GC后存活对象进入Survivor区经过一定次数的年龄递增后进入老年代大对象比如超过-XX:PretenureSizeThreshold的对象直接进入老年代。实际排查中我见到的OOM大多发生在堆上。常见原因包括内存泄漏对象被无意识持有、一次性加载大量数据、循环创建对象未释放引用。需要关注的JVM参数有-Xms初始堆、-Xmx最大堆、-Xmn新生代大小、-XX:MaxDirectMemorySize直接内存上限严格说不算堆但容易混淆。2.5 方法区与运行时常量池从永久代到元空间的变迁方法区存放类元信息、运行时常量池、静态变量、JIT编译后的代码等。在HotSpot虚拟机历史上方法区在JDK 7及以前用永久代PermGen实现当时如果加载的类太多会抛“java.lang.OutOfMemoryError: PermGen space”JDK 8之后改为元空间Metaspace并使用本地内存实现默认不再受限于JVM堆内存大小。运行时常量池是方法区的一部分存类文件常量池中的各种字面量和符号引用。String.intern()方法就和它有关——把字符串放入常量池时可以复用对象。JDK 7之后字符串常量池从永久代移到了堆中这也导致了一些字符串驻留和GC交互上的变化。一个容易踩坑的点元空间虽然用本地内存但不代表无限。容器环境下如果整个进程内存被限制元空间膨胀照样会把进程挤爆。所以线上环境我通常会设置-XX:MaxMetaspaceSize宁可频繁触发Full GC也不要让进程因本地内存耗尽被操作系统杀死。2.6 直接内存NIO和Netty性能的关键但不在堆内直接内存不是运行时数据区的正式成员但在JDK 4引入NIO后它变得不可或缺。它的特点是通过DirectByteBuffer分配不受Java堆大小限制受机器物理内存和-XX:MaxDirectMemorySize约束。为什么Netty和Kafka这类高性能框架偏爱直接内存因为当数据需要从磁盘或网络读写时使用直接内存可以避免一次“堆内内存 → 堆外内存”的数据拷贝直接进行I/O操作。代价是堆外内存的管理和回收不像堆内GC那么方便容易造成物理内存泄漏。实际经验如果项目用了Netty线上监控观察“进程RSS常驻内存持续增长但堆内存占用正常”大概率是直接内存泄漏。此时要看是否有DirectByteBuffer没有释放以及Netty的PooledByteBufAllocator配置是否合理。3. JMM的规则体系主内存、工作内存、原子操作与happens-before3.1 主内存和工作内存并不是堆和虚拟机栈的另一个叫法这是JMM里最容易混淆的一个地方。有人觉得“主内存就是堆工作内存就是虚拟机栈”这是不对的。JMM的主内存和工作内存是一个抽象概念它描述的是共享变量在线程间可见性的逻辑层级而堆和虚拟机栈是JVM内存区域的物理划分两者层次不同。在JMM的模型里所有共享变量存在主内存每个线程有自己的工作内存。线程对变量的所有操作读、写都必须在工作内存中完成不能直接操作主内存变量不同线程之间不能直接访问对方的工作内存线程间变量值的传递必须通过主内存完成。用两个人传纸条来类比主内存是公共告示板工作内存是各自的小本本。A在小本本上记了一个值必须把这张纸条贴到公共告示板上B才可能看到如果A一直不贴B永远不知道A记了什么。volatile就是强制“写完必须立刻贴到告示板上读的时候必须重新看告示板”的规则。3.2 八种原子操作从read到store看一个变量怎么跨线程流动JMM定义了八种原子操作来保证内存交互的可靠性lock把一个变量标记为线程独占状态。unlock把锁定状态的变量释放出来。read把一个主内存变量的值传输到线程的工作内存。load把read操作传来的值放入工作内存变量副本中。use把工作内存中的值传给执行引擎。assign把执行引擎计算得到的新值赋值给工作内存变量。store把工作内存变量的值传送回主内存。write把store操作传来的值写入主内存变量中。一条完整的写入链路是assign → store → write一条完整的读取链路是read → load → use。这些操作本身是原子的但组合起来不一定满足可见性和有序性所以还需要volatile和锁这样的高层同步机制兜底。3.3 volatile的可见性与有序性它的权利边界在哪儿volatile可以说是JMM规则最直接的实践产物。它有两个核心保证可见性写入volatile变量后JMM会立即将工作内存中的值刷新到主内存读取volatile变量时会强制从主内存重新加载。有序性volatile变量读写会插入内存屏障Memory Barrier禁止指令重排序跨越屏障。但很多人以为volatile也保证原子性这是误解。典型的反例是volatile int count上的count这个操作包含读取、加1、写回三个步骤不是原子性的。两个线程同时执行时仍然可能丢失更新。要保证原子性得用AtomicInteger、synchronized或者LongAdder。关于内存屏障的底层实现值得一提在x86体系下写volatile变量会触发StoreStore屏障和StoreLoad屏障读volatile变量会触发LoadLoad屏障和LoadStore屏障。这些屏障的作用是禁止CPU和编译器越过屏障乱序执行。面试时如果被深挖能说出屏障类型和插入位置会是很强的加分项。3.4 happens-before原则不需要锁也能保证顺序的规则集JMM用happens-before原则来界定“如果A happens-before B那么A的执行结果对B可见”。它是判断两个操作是否真的存在先后顺序的规则即使没有同步关键字也能依赖这些天然规则程序次序规则在一个线程内书写在前面的操作happens-before书写在后面的操作。监视器锁规则解锁操作happens-before后续对同一把锁的加锁操作。volatile变量规则对一个volatile变量的写操作happens-before后续对这个变量的读操作。传递性如果A happens-before BB happens-before C那么A happens-before C。线程启动规则Thread.start() happens-before被启动线程中的任何操作。线程终止规则线程中的所有操作happens-before其他线程检测到该线程终止比如Thread.join()返回。线程中断规则对线程的中断操作happens-before被中断线程检测到中断事件比如抛出InterruptedException。对象终结规则一个对象初始化完成happens-before它的finalize()方法调用。实际项目里happens-before最常用的场景就是安全发布对象通过volatile修饰引用确保对象构造函数中的赋值操作对另一个线程可见。4. 从线上故障反推概念三个真实问题的心路历程4.1 一次堆内存OOM排查jmap与MAT立功了某项目在压测阶段接口突然变慢随后整个应用频繁Full GC最后抛“java.lang.OutOfMemoryError: Java heap space”。我当时的排查链路是这样用jmap -heap查看堆配置和当前各区使用情况发现老年代几乎占满新生代GC后存活对象大量进入老年代。用jmap -dump:formatb,fileheap.hprof生成堆转储文件导入MATMemory Analyzer Tool分析。MAT的Dominator Tree显示有个缓存对象占据了约70%的堆空间。进一步查看引用链发现是项目中一个静态Map没有做容量控制业务请求不断往里塞数据从不清理。修复方式很简单改用带过期策略的本地缓存比如Caffeine并限制最大条数。复盘时我重新理解了“堆是共享的”意味着什么静态集合本质上就是一个全局的GC Root只要它不变空里面的对象永远不会被回收。这也提醒我凡是往全局集合里放数据都得先回答一个问题这个数据什么时候被移除4.2 栈内存过小导致的诡异故障递归并非唯一元凶另一个案例是某服务运行一段时间后线程突然大量报StackOverflowError。起初以为是某个递归方法死循环但翻代码发现递归深度并不大。后来用jstack抓线程转储发现大量线程阻塞在一个网络调用的等待逻辑上而这个调用内部使用了嵌套同步块导致线程持有锁不放。锁竞争加剧后线程等待期间又不断有新的任务被提交到线程池线程栈内存无限累积最终栈深度超过-Xss设置值。排查完成后我意识到虚拟机和操作系统是两套资源体系线程的栈内存不在堆内不能用堆的监控覆盖栈的监控。线上环境应该对每个容器的线程数做实时监控必要时用-XX:ThreadStackSize合理调整或设置线程池上限。4.3 并发计数Bug复现volatile为什么救不了count复现环境很简单两个线程同时对同一个volatile变量执行100万次自增最终结果远小于200万。我带着团队做了一次现场演示用javap -c查看字节码发现count被拆成了四条字节码指令getstatic count iconst_1 iadd putstatic count在线程切换的间隙两个线程可能同时读到同一个count值分别加1后写回等于只加了一次。这个案例比任何理论解释都能说服人可见性解决的是“读到的旧值”问题原子性解决的是“一旦读出来、加完、写回这三个步骤被拆开”的问题。最终方案是改用LongAdder因为它内部把热点拆成了多个Cell并发下分散竞争再通过sum()汇总结果既保证最终一致性又能避免单一原子变量带来的CAS竞争。4.4 元空间需要被监控类加载器泄漏没有想象中那么少还有一个案例和动态代理有关。某项目用CGLIB频繁生成代理类同时自定义类加载器没有正确回收导致每次生成新代理类都往元空间塞入新的类元数据。上线几天后元空间占用持续上升最终进程被操作系统OOMKiller杀掉。这个故障的排查相对曲折常规的堆转储分析看不到元空间内部因为类元数据不占Java堆。后来通过JMX监控java.lang.management.MemoryMXBean里的NonHeapMemoryUsage再配合-verbose:class观察实际加载的类名规律才定位到动态代理类数量异常。修复方式是限制类加载器的数量、复用已有的代理类对象并在容器层面设置-XX:MaxMetaspaceSize作为兜底。这个案例让我正视了一个事实JVM的每一块内存区域都值得单独监控只盯着堆内存远远不够。5. 实战中的五个常见认知误区与排查思路5.1 误区一以为“对象只在堆上分配”严格来说经过逃逸分析确认对象不会被外部访问HotSpot会把对象直接分配到线程栈上方法结束后栈帧弹出即回收无需GC介入。这种优化叫栈上分配Stack Allocation利用的是标量替换技术——把一个对象拆成若干个基本类型变量。JVM参数-server -XX:DoEscapeAnalysis -XX:EliminateAllocations在JDK 8默认为开启状态。如果你的代码里有只在线程内部使用的小对象就不必担心GC压力。但要注意一旦对象被方法返回、存入静态字段或逃逸到其他线程栈上分配自动失效。5.2 误区二以为“volatile保证线程安全”这是个老生常谈的认知偏差。volatile保证的是可见性和有序性不保证复合操作的原子性。判断一个变量是否适合用volatile可以问三个问题这个变量的值会被多个线程同时修改吗如果会且修改不是原子操作volatile不够。这个变量作为状态标志只要保证一个线程改了另一个线程立刻看到volatile足够。是否有依赖当前值的操作如自增、先判断再赋值有就不够。实际开发中volatile最常见的安全用例就是“状态开关”比如private volatile boolean running true;另一个线程通过判断running来控制循环退出。5.3 误区三把“主内存”直接对应到“堆内存”上文已经强调过JMM主内存是一个抽象概念。线程的工作内存对应到物理层面可能是CPU的寄存器、L1/L2缓存也可能一部分是堆内存取决于JVM实现。所以不要试图用jstat或者jmap去“查看”JMM的主内存它是逻辑模型不是可观测内存块。这种抽象的最大价值在于它告诉程序员不需要关心CPU缓存一致性协议、不需要关心具体处理器架构只要按照Java内存模型编写并发代码就能获得跨平台的内存可见性保证。5.4 误区四忽略安全点SafePoint对GC和线程转储的影响GC触发时线程必须在安全点停顿这个机制虽然不属于JMM的正式内容但实际观察线程状态时需要理解。jstack中的“vm_thread”或“running”状态有时候并不代表线程真的在干活而是在等待进入安全点。排查响应缓慢问题时如果发现GC日志显示安全点停顿时间过长同时大量线程处于可运行但实际未推进的状态说明STWStop-The-World过长需要考虑降低GC频率或改用低延迟垃圾收集器。5.5 误区五把“内存溢出”和“内存泄漏”混为一谈内存溢出Memory Overflow是分配不出内存时抛出的异常内存泄漏Memory Leak是对象该回收但没有被回收持续占用内存。泄漏往往是溢出的前因但有些溢出并不伴随泄漏——比如一次性加载超大文件修改代码、限制单批数据量即可解决。排查内存泄漏除了堆转储分析还要关注GC日志中“老年代使用率是否持续上升”以及通过VisualVM/JConsole观察内存使用曲线。如果使用率每轮GC后降不下来基本可以判定有对象被长期引用。6. 写在最后的排查清单高性能并发服务的两个必备视角我在实际项目中养成了一个习惯遇到内存或并发问题先确定自己站在哪个“坐标系”里。如果是对象太多、堆不够用切到运行时数据区的视图如果是数据改了别人看不见、指令被重排切到JMM的视图。两个视角分开看问题往往比混在一起排查更高效。最后分享一份实用的自查清单先看堆内存曲线和GC日志判断是内存泄漏还是内存溢出这决定后面走哪条路。再用jstack看线程状态有没有大量BLOCKED、WAITING或死锁尤其是等待GC安全点的线程。如果存在并发可见性问题优先检查共享变量是否被volatile修饰复合操作是否加了锁。每块独立内存区域都必须有监控堆、元空间、直接内存、线程栈缺哪个都可能出大事。线上服务建议至少设置-Xmx、-XX:MaxMetaspaceSize、-XX:MaxDirectMemorySize三个上限避免进程级失控。JVM运行时数据区和Java内存模型一个管空间一个管规则。把它们的差别刻在脑子里面试时能讲得清楚出问题时能快速定位方向——这两件事是同一件事的两面。