如果你在网上搜索“JVM内存结构”能找到的图解和文章多到能把人淹没。可这几年我面试过的Java候选人里至少有一半会把“内存结构”和“内存模型”混为一谈或者在问堆和栈的区别时把参数、回收器、异常类型搅成一锅粥。这很可惜因为JVM内存结构并不难它就是一个静态的骨架只要把各个区域的作用、归属、生命周期和异常类型梳理清楚后面学GC、学调优、甚至看字节码都会顺畅很多。这篇文章不只是写给准备面试的人也写给正在被线上OOM、Gradle构建内存崩溃搞到头大的开发。我会从JVM和JRE的关系开始讲把运行时数据区的每一块区域拆开说明再结合常见参数、监控命令和真实故障排查把内存结构这部分内容真正落到地面。1. 先理清一个前提JVM内存结构到底在讲什么1.1 内存结构不等于内存模型别再混着答我见过很多简历上写着“熟悉JVM”结果面试官一问“你说一下JVM内存结构”开口就是“主内存、工作内存、可见性、原子性”。这不是JVM内存结构这是Java内存模型Java Memory ModelJMM。两者名字太像但聊的完全是两码事。JVM内存结构指的是Java虚拟机在运行时的若干数据区域包括程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区等回答的问题是“程序跑起来之后对象、变量、常量、类元数据分别存在哪些地方”。JMM则是Java语言规范定义的一种抽象内存模型关注的是多线程下共享变量的可见性和有序性规则回答的是“一个线程在什么时间点能看到另一个线程写入的值”。如果你先分清这两个概念后续的学习基本不会迷路。这也是JVM相关面试题里最容易拿分也最容易送分的地方。1.2 从JRE和JVM的关系看内存是谁分配的继续说背景。JVM的全称是Java Virtual Machine它本质上是一个运行在操作系统进程里的虚拟机程序。而JRE是Java Runtime Environment也就是Java运行环境里面装着一套JVM实现、Java核心类库和一些辅助文件。你的Java程序编译成字节码之后由JVM负责解释或编译执行同时JVM需要向操作系统申请内存再按照规范把这块内存划成几个区域。所以网上常说的“JVM内存结构”严格来说指的就是JVM规范里的运行时数据区。《Java虚拟机规范Java SE 8版》把运行时数据区划分成五块程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区。如果再把JDK 8之后越来越常用的直接内存算进来实践中其实要关注六块。前三个区域是线程私有的生命周期和线程一致后三个是线程共享的垃圾回收主要针对Java堆和部分方法区。这个划分不是为了好看而是为了贴合传统编程模型每个线程需要独立的执行上下文所以要有私有的栈和程序计数器所有线程又需要共享对象和方法元数据所以要有公共的堆和方法区。2. 按区域拆解每个内存区都在干什么2.1 程序计数器是唯一不会OOM的区域程序计数器Program Counter Register是一块很小的内存空间可以看作当前线程所执行字节码的行号指示器。字节码解释器工作时就是通过修改这个计数器的值来选取下一条需要执行的字节码指令。它是线程私有的因为线程切换时要能恢复到正确的执行位置所以每个线程都得有一条独立的计数器。如果执行的是Java方法计数器记录的是正在执行的虚拟机字节码地址如果是native方法计数器的值是Undefined。这块区域在《Java虚拟机规范》里没有规定任何OutOfMemoryError情况也是运行时数据区里唯一不会OOM的区域。面试问到“哪些区域会内存溢出”时程序计数器是唯一的例外很多人会漏掉这一点。你甚至不用给它设置任何参数它天然就是安全的。2.2 Java虚拟机栈每次方法调用都在这里“搭积木”Java虚拟机栈也是线程私有的生命周期和线程相同。每次进入一个方法JVM都会创建对应的栈帧方法执行完就出栈。栈帧里主要装着四样东西局部变量表存放方法参数和方法内部定义的局部变量。注意这里存的是基本类型值或对象引用对象本体依然放在堆里。操作数栈一个后进先出的栈结构字节码指令的中间计算在这里完成。比如执行加法指令时先把两个操作数压栈再从栈顶取出相加结果再压回去。动态链接指向运行时常量池中该方法的引用用来支持方法调用时的动态绑定。方法出口保存正常返回地址或异常处理时需要的上层方法信息。说实话面试时很少让你把栈帧结构完整背下来但你要能说清楚一点栈存储的是方法调用信息不是对象数据。所以“对象是放在栈里还是堆里”这个最常考的判断题标准答案是对象在堆里栈里只有引用和基本类型值。栈大小可以是固定的也可以动态扩展。固定大小情况下如果线程请求的栈深度超出可用深度会抛StackOverflowError动态扩展时申请不到内存则抛OutOfMemoryError。生产上常见的是StackOverflowError典型场景是递归没有终止条件或循环调用层次过深。遇到这类错误先看栈顶日志很快就能定位到问题方法。2.3 本地方法栈被忽略的第三块私有区域本地方法栈和Java虚拟机栈的作用几乎一样区别只在于它是为native方法服务的。说得直白点如果某个方法用native关键字修饰比如Object.hashCode对应的底层实现或者JNI调用C/C代码执行时需要的内存栈就是本地方法栈。HotSpot虚拟机在实现时把本地方法栈和Java虚拟机栈合并成了一个所以用jmap之类工具看HotSpot的内存分布不一定能看到单独的一块“本地方法栈”。但在规范层面它们确实分开存在面试中要能承认这一点。本地方法栈同样可能抛StackOverflowError和OutOfMemoryError排查方式和Java虚拟机栈基本一致。2.4 Java堆内存结构的绝对主角Java堆是运行时数据区里最大的一块也是所有线程共享的区域。对象实例和数组基本都在这里分配内存。堆由垃圾回收器统一管理所以GC的大部分工作都发生在这里。从内存划分上看HotSpot的堆被分成新生代和老年代新生代再细分为Eden区、From Survivor区和To Survivor区默认比例是8:1:1。新对象通常先进Eden区Minor GC之后幸存的对象会被移到Survivor区年龄足够大后晋升到老年代。大对象也可以通过参数直接分配到老年代。初学阶段最容易犯的错是以为堆就是一块均匀的平地。其实堆可以通过-XX:NewRatio、-Xmn等参数做更细的布局这个布局直接影响GC效率和停顿时间。堆会不会抛OOM答案是会。当堆空间不足以分配新对象且GC无法回收足够空间时会抛java.lang.OutOfMemoryError: Java heap space。无休止创建缓存、泄漏对象、加载超大数据量基本都会在这里爆掉。2.5 方法区与元空间永久代到底去哪了方法区在逻辑上也是线程共享的存放的是类型的类元数据、静态变量、常量池等重要信息。Java 7之前HotSpot习惯把方法区叫作永久代并且放在堆的独立区域里管理。Java 8之后永久代被彻底移除取而代之的是元空间而元空间默认使用本地内存。为什么要移除永久代主要原因有两个。一是永久代会参与Full GC但永久代内容本身的回收条件非常苛刻经常出现类加载器泄漏导致永久代OOM。二是永久代默认大小有限动态代理、CGLIB生成类一多就容易溢出而且调大永久代又会占用堆内存设计上很别扭。改成元空间后类元数据不再占用堆内存默认情况下可以使用系统内存Full GC压力也小了一些。JDK 8之后参数也要跟着变以前调-XX:PermSize和-XX:MaxPermSize现在要调-XX:MetaspaceSize和-XX:MaxMetaspaceSize。不过注意MetaspaceSize并不是“初始大小”那么简单它可以视为触发类元数据回收的阈值实际占用超过后会触发GC并动态调整。2.6 直接内存不在JVM管辖内的那部分直接内存指的是通过DirectByteBuffer等方式在堆外分配的内存它不是JVM运行时数据区的一部分但在使用NIO、Netty时地位非常高。这样做的好处是省掉从操作系统内核态到用户态的拷贝读写性能更好代价是需要手动管理释放而且它依然算在进程内存里。直接内存默认没有明确上限大小受宿主机剩余内存限制。线上最常见的问题是堆内存监控一切正常进程却莫名其妙被OOM Killer杀掉或者报“Cannot allocate native memory”。这种时候除了看堆还要排查直接内存和本地内存。配置时可以通过-XX:MaxDirectMemorySize限制直接内存大小实际开发中NIO框架一般会默认使用它。3. 内存结构如何与垃圾回收协作3.1 分代收集到底分的是什么区域很多人以为分代收集是整块JVM内存都在分严格来说分代是堆内存的安排方法区和线程私有区域并不参与对象分代。新生代放“朝生夕灭”的对象老年代放“活得很久”的对象这个设计基于一条统计规律绝大多数对象在创建之后很快就可以被回收。分代后可以按区域采用不同策略的回收器新生代用复制算法老年代用标记整理或标记清除效率和吞吐量都更有保障。分代设计里有个容易被忽略的点Survivor区为什么要分From和To两块因为复制算法要求把存活对象从一块区域复制到另一块留出另一块空白区域作为后续分配备用空间。没有这个双缓冲区设计复制算法就无法在堆里连续完成对象复制目标会互相覆盖。这也是老年代不适合复制算法的原因——老年代存活对象太多复制成本太高不如用标记整理。3.2 不同GC回收器怎么适配内存分区从内存结构角度看垃圾回收器主要围绕堆来设计。Serial和Parallel采用单线程或多线程并行回收新生代和老年代内存划分相对简单CMS放弃了对老年代的压缩整理导致老年代碎片化严重G1则打破了固定分区思维把整个堆划分成很多大小相同的Region新生代和老年代不再有明显连续分界。G1值得重点了解。它把整块堆按默认2048个Region来划分每个Region可以是Eden、Survivor或Old其中一种通过记录每个Region的回收收益优先处理回收性价比高的区域。所以G1在内存结构上不再依赖新生代、老年代的具体物理边界-XX:NewRatio对G1的意义也减弱了。面试被问“G1凭什么能做到可预测停顿”追根溯源就是因为它把连续分区改成了可动态演变的Region模型。3.3 逃逸分析、栈上分配与TLAB常规理解是“对象都在堆上分配”但现代JVM开启逃逸分析后会尝试把不逃逸的对象直接分配在栈上或者做标量替换让一部分对象不用真正在堆里占空间。这类优化能降低GC压力但并不是所有对象都适合。如果对象被方法返回、放入成员变量或集合就属于逃逸对象仍然必须堆上分配。还有一个细节容易被忽略生产环境默认开启TLAB也就是每个线程在Eden区里预分配一小块私有缓冲区这样线程分配对象时不需要抢占全局锁减少竞争。TLAB空间不足时会退回到全局分配同时可能触发Minor GC。面试题问到“多线程在堆上分配对象要不要加锁”本质就在考TLAB的存在。4. 实操JVM内存监控命令与参数配置4.1 三个最常用的命令jps、jstat、jmap理论说完直接上工具。我建议先把下面三件套练熟jps列出Java进程的pid和主类名。很多新人上来就用jmap结果找不到进程得先jps确认。jstat -gc 1000每秒输出一次GC统计看S0C、S1C、EC、OC、MC这些分区容量以及YGC、FGC次数和耗时。看FGC是否上涨过快、YGC是否过频这是一眼判断内存配置是否合理的方法。jmap -heap 打印堆内各区域的容量和使用率以及JVM实际生效的参数。这个命令在线下排查很好用特别适合确认堆到底有多大、新生代和老年代分别多大。如果是生产环境建议少用jmap和jcmd的dump类操作因为比较影响性能。可以把堆转储文件拉回本地之后用MAT或VisualVM分析。4.2 常用堆参数怎么选继续讲参数。常用JVM堆内存参数大概有这些参数作用-Xms堆初始大小-Xmx堆最大大小-Xmn新生代大小-XX:NewRatio新生代和老年代比例默认2表示老年代是新生代2倍-XX:SurvivorRatioEden区和单个Survivor区比例默认8-XX:MetaspaceSize元空间触发GC的阈值-XX:MaxMetaspaceSize元空间最大大小-XX:MaxDirectMemorySize直接内存上限-Xms和-Xmx建议设置成相同值避免运行时动态扩容触发停顿。如果服务是IO密集型但对象生命周期短可以适当调大-Xmn如果缓存多、存活时间长的对象多则要保证老年代足够。别直接抄网上“一律改4G”的配置先确认你的机器内存和部门运维基准再说。4.3 一次线上堆OOM排查复盘我遇到过这样一个Spring Boot服务线上突然报OutOfMemoryError: Java heap space。第一步用jps找到pid然后jmap -heap看堆使用发现已经满了。再jstat一看FGC频繁且每次耗时超过2秒说明存在大量不可回收对象。因为没有加-XX:HeapDumpOnOutOfMemoryError线上也没保留dump只能通过jcmd临时触发一次堆转储拉回本地用MAT分析。用MAT打开后发现绝大多数内存被同一个ConcurrentHashMap持有里面存放大量带时间戳的历史缓存数据。代码里只做了写入没有考虑过期清理等于把过期数据无限累积到内存。这个案例给我两个教训第一项目启动脚本必须提前加上-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath否则事后排查要多花几倍时间第二很多OOM根本不是GC参数太小而是业务代码没把数据清理干净先查业务对象再调参。5. 面试和构建工具常见问题实录5.1 面试最常考的内存结构问题把JVM内存结构相关面试题整理一下高频的无非是这么几类JVM内存区域有哪些哪些线程私有哪些线程共享Java堆的分代结构是什么对象是怎么分配和晋升的栈和堆有什么区别什么是元空间和永久代有什么区别哪些区域会抛StackOverflowError哪些会抛OutOfMemoryErrorOOM主要类型有哪些Java heap space和Metaspace OOM的原因各是什么栈和堆的区别是最高频的。我的回答思路是从用途上说栈存方法调用帧和局部变量栈越大代表方法嵌套越深堆存对象实例堆越大代表应用数据量越大。从生命周期看栈帧随方法调用生成、结束后销毁堆对象则需要靠GC回收。从异常类型看栈溢出是StackOverflowError堆空间不足是OutOfMemoryError。把这三层分开讲基本能自然引导到下一个问题。5.2 StackOverflowError和OOM的边界StackOverflowError常见于递归没出口、循环调用嵌套过深、AOP代理连锁回调等场景。它和OOM不一样一般不是内存不够而是当前线程请求的栈容量超出了最大深度。排查时第一件事不是调-Xss而是看栈顶帧元素定位到递归调用链通常添加递归终止条件或改成循环就能解决。只有确认代码确实没问题确实需要增加方法嵌套深度时才考虑调大-Xss。OOM的类型再多内存结构里能关联的也就那几种Java堆OOM对应堆空间耗尽元空间OOM对应类元数据增长过快直接内存OOM对应NIO或Netty缓冲区设置过大还有一个GC overhead limit exceeded是GC反复回收却收不出空间时的保护机制。日常95%的OOM都能通过“堆转储业务代码审查”解决别一看到OOM就直接堆参数。5.3 Gradle构建中的JVM堆空间与JVM Options报错如果你用Gradle构建时遇到“Expiring daemon because JVM heap space is exhausted”本质上是Gradle守护进程的堆内存被占满Gradle会自动让旧daemon过期再启动新daemon。解决办法是在项目根目录的gradle.properties里调整守护进程参数org.gradle.jvmargs-Xmx2048m -XX:MaxMetaspaceSize512m这里要特别提醒Gradle守护进程是独立JVM它并不等于你的应用JVM。很多人给应用配了-Xmx4g结果构建还是崩因为Gradle daemon走的是gradle.properties里的org.gradle.jvmargs和应用启动脚本里的参数是两条线。还有一个容易踩的坑就是遇到“cannot collect jvm options caused by: 0: cannot read: d:v作业实训 vjetbrain_”这类报错。这个一般是Gradle或者IDE读取JVM options时配置文件里写了不合法路径或者Windows路径格式有问题。比如gradle.properties中的org.gradle.jvmargs出现引号缺失、路径带空格没转义或者IDEA的Gradle JVM选项里误填了不存在的目录。我的处理顺序是先看gradle.properties里有没有奇怪的jvmargs再检查IDEA设置里的Gradle JVM options是否指向正确路径最后去用户目录的.gradle/gradle.properties里搜索可疑配置。清理干净后重启IDE和Gradle daemon一般就能恢复。我自己长期在用的配置是这样org.gradle.jvmargs-Xmx2048m -Dfile.encodingUTF-8不要在配置里写中文目录也尽量不要用相对路径Windows下路径分隔符统一用正斜杠更省心。最后再分享一个小习惯我写任何Java服务启动脚本里都会固定带上-XX:HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath和GC日志参数看着麻烦但每次出现线上问题时这些日志都能帮我把故障时间线准确还原。内存结构这块内容看着偏概念但只要把每个区域各自能干什么、各自会出什么异常都理顺之后遇到再复杂的内存性能问题心里都会有个底。
JVM内存结构全解析：从堆栈到元空间，掌握OOM排查与调优
如果你在网上搜索“JVM内存结构”能找到的图解和文章多到能把人淹没。可这几年我面试过的Java候选人里至少有一半会把“内存结构”和“内存模型”混为一谈或者在问堆和栈的区别时把参数、回收器、异常类型搅成一锅粥。这很可惜因为JVM内存结构并不难它就是一个静态的骨架只要把各个区域的作用、归属、生命周期和异常类型梳理清楚后面学GC、学调优、甚至看字节码都会顺畅很多。这篇文章不只是写给准备面试的人也写给正在被线上OOM、Gradle构建内存崩溃搞到头大的开发。我会从JVM和JRE的关系开始讲把运行时数据区的每一块区域拆开说明再结合常见参数、监控命令和真实故障排查把内存结构这部分内容真正落到地面。1. 先理清一个前提JVM内存结构到底在讲什么1.1 内存结构不等于内存模型别再混着答我见过很多简历上写着“熟悉JVM”结果面试官一问“你说一下JVM内存结构”开口就是“主内存、工作内存、可见性、原子性”。这不是JVM内存结构这是Java内存模型Java Memory ModelJMM。两者名字太像但聊的完全是两码事。JVM内存结构指的是Java虚拟机在运行时的若干数据区域包括程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区等回答的问题是“程序跑起来之后对象、变量、常量、类元数据分别存在哪些地方”。JMM则是Java语言规范定义的一种抽象内存模型关注的是多线程下共享变量的可见性和有序性规则回答的是“一个线程在什么时间点能看到另一个线程写入的值”。如果你先分清这两个概念后续的学习基本不会迷路。这也是JVM相关面试题里最容易拿分也最容易送分的地方。1.2 从JRE和JVM的关系看内存是谁分配的继续说背景。JVM的全称是Java Virtual Machine它本质上是一个运行在操作系统进程里的虚拟机程序。而JRE是Java Runtime Environment也就是Java运行环境里面装着一套JVM实现、Java核心类库和一些辅助文件。你的Java程序编译成字节码之后由JVM负责解释或编译执行同时JVM需要向操作系统申请内存再按照规范把这块内存划成几个区域。所以网上常说的“JVM内存结构”严格来说指的就是JVM规范里的运行时数据区。《Java虚拟机规范Java SE 8版》把运行时数据区划分成五块程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区。如果再把JDK 8之后越来越常用的直接内存算进来实践中其实要关注六块。前三个区域是线程私有的生命周期和线程一致后三个是线程共享的垃圾回收主要针对Java堆和部分方法区。这个划分不是为了好看而是为了贴合传统编程模型每个线程需要独立的执行上下文所以要有私有的栈和程序计数器所有线程又需要共享对象和方法元数据所以要有公共的堆和方法区。2. 按区域拆解每个内存区都在干什么2.1 程序计数器是唯一不会OOM的区域程序计数器Program Counter Register是一块很小的内存空间可以看作当前线程所执行字节码的行号指示器。字节码解释器工作时就是通过修改这个计数器的值来选取下一条需要执行的字节码指令。它是线程私有的因为线程切换时要能恢复到正确的执行位置所以每个线程都得有一条独立的计数器。如果执行的是Java方法计数器记录的是正在执行的虚拟机字节码地址如果是native方法计数器的值是Undefined。这块区域在《Java虚拟机规范》里没有规定任何OutOfMemoryError情况也是运行时数据区里唯一不会OOM的区域。面试问到“哪些区域会内存溢出”时程序计数器是唯一的例外很多人会漏掉这一点。你甚至不用给它设置任何参数它天然就是安全的。2.2 Java虚拟机栈每次方法调用都在这里“搭积木”Java虚拟机栈也是线程私有的生命周期和线程相同。每次进入一个方法JVM都会创建对应的栈帧方法执行完就出栈。栈帧里主要装着四样东西局部变量表存放方法参数和方法内部定义的局部变量。注意这里存的是基本类型值或对象引用对象本体依然放在堆里。操作数栈一个后进先出的栈结构字节码指令的中间计算在这里完成。比如执行加法指令时先把两个操作数压栈再从栈顶取出相加结果再压回去。动态链接指向运行时常量池中该方法的引用用来支持方法调用时的动态绑定。方法出口保存正常返回地址或异常处理时需要的上层方法信息。说实话面试时很少让你把栈帧结构完整背下来但你要能说清楚一点栈存储的是方法调用信息不是对象数据。所以“对象是放在栈里还是堆里”这个最常考的判断题标准答案是对象在堆里栈里只有引用和基本类型值。栈大小可以是固定的也可以动态扩展。固定大小情况下如果线程请求的栈深度超出可用深度会抛StackOverflowError动态扩展时申请不到内存则抛OutOfMemoryError。生产上常见的是StackOverflowError典型场景是递归没有终止条件或循环调用层次过深。遇到这类错误先看栈顶日志很快就能定位到问题方法。2.3 本地方法栈被忽略的第三块私有区域本地方法栈和Java虚拟机栈的作用几乎一样区别只在于它是为native方法服务的。说得直白点如果某个方法用native关键字修饰比如Object.hashCode对应的底层实现或者JNI调用C/C代码执行时需要的内存栈就是本地方法栈。HotSpot虚拟机在实现时把本地方法栈和Java虚拟机栈合并成了一个所以用jmap之类工具看HotSpot的内存分布不一定能看到单独的一块“本地方法栈”。但在规范层面它们确实分开存在面试中要能承认这一点。本地方法栈同样可能抛StackOverflowError和OutOfMemoryError排查方式和Java虚拟机栈基本一致。2.4 Java堆内存结构的绝对主角Java堆是运行时数据区里最大的一块也是所有线程共享的区域。对象实例和数组基本都在这里分配内存。堆由垃圾回收器统一管理所以GC的大部分工作都发生在这里。从内存划分上看HotSpot的堆被分成新生代和老年代新生代再细分为Eden区、From Survivor区和To Survivor区默认比例是8:1:1。新对象通常先进Eden区Minor GC之后幸存的对象会被移到Survivor区年龄足够大后晋升到老年代。大对象也可以通过参数直接分配到老年代。初学阶段最容易犯的错是以为堆就是一块均匀的平地。其实堆可以通过-XX:NewRatio、-Xmn等参数做更细的布局这个布局直接影响GC效率和停顿时间。堆会不会抛OOM答案是会。当堆空间不足以分配新对象且GC无法回收足够空间时会抛java.lang.OutOfMemoryError: Java heap space。无休止创建缓存、泄漏对象、加载超大数据量基本都会在这里爆掉。2.5 方法区与元空间永久代到底去哪了方法区在逻辑上也是线程共享的存放的是类型的类元数据、静态变量、常量池等重要信息。Java 7之前HotSpot习惯把方法区叫作永久代并且放在堆的独立区域里管理。Java 8之后永久代被彻底移除取而代之的是元空间而元空间默认使用本地内存。为什么要移除永久代主要原因有两个。一是永久代会参与Full GC但永久代内容本身的回收条件非常苛刻经常出现类加载器泄漏导致永久代OOM。二是永久代默认大小有限动态代理、CGLIB生成类一多就容易溢出而且调大永久代又会占用堆内存设计上很别扭。改成元空间后类元数据不再占用堆内存默认情况下可以使用系统内存Full GC压力也小了一些。JDK 8之后参数也要跟着变以前调-XX:PermSize和-XX:MaxPermSize现在要调-XX:MetaspaceSize和-XX:MaxMetaspaceSize。不过注意MetaspaceSize并不是“初始大小”那么简单它可以视为触发类元数据回收的阈值实际占用超过后会触发GC并动态调整。2.6 直接内存不在JVM管辖内的那部分直接内存指的是通过DirectByteBuffer等方式在堆外分配的内存它不是JVM运行时数据区的一部分但在使用NIO、Netty时地位非常高。这样做的好处是省掉从操作系统内核态到用户态的拷贝读写性能更好代价是需要手动管理释放而且它依然算在进程内存里。直接内存默认没有明确上限大小受宿主机剩余内存限制。线上最常见的问题是堆内存监控一切正常进程却莫名其妙被OOM Killer杀掉或者报“Cannot allocate native memory”。这种时候除了看堆还要排查直接内存和本地内存。配置时可以通过-XX:MaxDirectMemorySize限制直接内存大小实际开发中NIO框架一般会默认使用它。3. 内存结构如何与垃圾回收协作3.1 分代收集到底分的是什么区域很多人以为分代收集是整块JVM内存都在分严格来说分代是堆内存的安排方法区和线程私有区域并不参与对象分代。新生代放“朝生夕灭”的对象老年代放“活得很久”的对象这个设计基于一条统计规律绝大多数对象在创建之后很快就可以被回收。分代后可以按区域采用不同策略的回收器新生代用复制算法老年代用标记整理或标记清除效率和吞吐量都更有保障。分代设计里有个容易被忽略的点Survivor区为什么要分From和To两块因为复制算法要求把存活对象从一块区域复制到另一块留出另一块空白区域作为后续分配备用空间。没有这个双缓冲区设计复制算法就无法在堆里连续完成对象复制目标会互相覆盖。这也是老年代不适合复制算法的原因——老年代存活对象太多复制成本太高不如用标记整理。3.2 不同GC回收器怎么适配内存分区从内存结构角度看垃圾回收器主要围绕堆来设计。Serial和Parallel采用单线程或多线程并行回收新生代和老年代内存划分相对简单CMS放弃了对老年代的压缩整理导致老年代碎片化严重G1则打破了固定分区思维把整个堆划分成很多大小相同的Region新生代和老年代不再有明显连续分界。G1值得重点了解。它把整块堆按默认2048个Region来划分每个Region可以是Eden、Survivor或Old其中一种通过记录每个Region的回收收益优先处理回收性价比高的区域。所以G1在内存结构上不再依赖新生代、老年代的具体物理边界-XX:NewRatio对G1的意义也减弱了。面试被问“G1凭什么能做到可预测停顿”追根溯源就是因为它把连续分区改成了可动态演变的Region模型。3.3 逃逸分析、栈上分配与TLAB常规理解是“对象都在堆上分配”但现代JVM开启逃逸分析后会尝试把不逃逸的对象直接分配在栈上或者做标量替换让一部分对象不用真正在堆里占空间。这类优化能降低GC压力但并不是所有对象都适合。如果对象被方法返回、放入成员变量或集合就属于逃逸对象仍然必须堆上分配。还有一个细节容易被忽略生产环境默认开启TLAB也就是每个线程在Eden区里预分配一小块私有缓冲区这样线程分配对象时不需要抢占全局锁减少竞争。TLAB空间不足时会退回到全局分配同时可能触发Minor GC。面试题问到“多线程在堆上分配对象要不要加锁”本质就在考TLAB的存在。4. 实操JVM内存监控命令与参数配置4.1 三个最常用的命令jps、jstat、jmap理论说完直接上工具。我建议先把下面三件套练熟jps列出Java进程的pid和主类名。很多新人上来就用jmap结果找不到进程得先jps确认。jstat -gc 1000每秒输出一次GC统计看S0C、S1C、EC、OC、MC这些分区容量以及YGC、FGC次数和耗时。看FGC是否上涨过快、YGC是否过频这是一眼判断内存配置是否合理的方法。jmap -heap 打印堆内各区域的容量和使用率以及JVM实际生效的参数。这个命令在线下排查很好用特别适合确认堆到底有多大、新生代和老年代分别多大。如果是生产环境建议少用jmap和jcmd的dump类操作因为比较影响性能。可以把堆转储文件拉回本地之后用MAT或VisualVM分析。4.2 常用堆参数怎么选继续讲参数。常用JVM堆内存参数大概有这些参数作用-Xms堆初始大小-Xmx堆最大大小-Xmn新生代大小-XX:NewRatio新生代和老年代比例默认2表示老年代是新生代2倍-XX:SurvivorRatioEden区和单个Survivor区比例默认8-XX:MetaspaceSize元空间触发GC的阈值-XX:MaxMetaspaceSize元空间最大大小-XX:MaxDirectMemorySize直接内存上限-Xms和-Xmx建议设置成相同值避免运行时动态扩容触发停顿。如果服务是IO密集型但对象生命周期短可以适当调大-Xmn如果缓存多、存活时间长的对象多则要保证老年代足够。别直接抄网上“一律改4G”的配置先确认你的机器内存和部门运维基准再说。4.3 一次线上堆OOM排查复盘我遇到过这样一个Spring Boot服务线上突然报OutOfMemoryError: Java heap space。第一步用jps找到pid然后jmap -heap看堆使用发现已经满了。再jstat一看FGC频繁且每次耗时超过2秒说明存在大量不可回收对象。因为没有加-XX:HeapDumpOnOutOfMemoryError线上也没保留dump只能通过jcmd临时触发一次堆转储拉回本地用MAT分析。用MAT打开后发现绝大多数内存被同一个ConcurrentHashMap持有里面存放大量带时间戳的历史缓存数据。代码里只做了写入没有考虑过期清理等于把过期数据无限累积到内存。这个案例给我两个教训第一项目启动脚本必须提前加上-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath否则事后排查要多花几倍时间第二很多OOM根本不是GC参数太小而是业务代码没把数据清理干净先查业务对象再调参。5. 面试和构建工具常见问题实录5.1 面试最常考的内存结构问题把JVM内存结构相关面试题整理一下高频的无非是这么几类JVM内存区域有哪些哪些线程私有哪些线程共享Java堆的分代结构是什么对象是怎么分配和晋升的栈和堆有什么区别什么是元空间和永久代有什么区别哪些区域会抛StackOverflowError哪些会抛OutOfMemoryErrorOOM主要类型有哪些Java heap space和Metaspace OOM的原因各是什么栈和堆的区别是最高频的。我的回答思路是从用途上说栈存方法调用帧和局部变量栈越大代表方法嵌套越深堆存对象实例堆越大代表应用数据量越大。从生命周期看栈帧随方法调用生成、结束后销毁堆对象则需要靠GC回收。从异常类型看栈溢出是StackOverflowError堆空间不足是OutOfMemoryError。把这三层分开讲基本能自然引导到下一个问题。5.2 StackOverflowError和OOM的边界StackOverflowError常见于递归没出口、循环调用嵌套过深、AOP代理连锁回调等场景。它和OOM不一样一般不是内存不够而是当前线程请求的栈容量超出了最大深度。排查时第一件事不是调-Xss而是看栈顶帧元素定位到递归调用链通常添加递归终止条件或改成循环就能解决。只有确认代码确实没问题确实需要增加方法嵌套深度时才考虑调大-Xss。OOM的类型再多内存结构里能关联的也就那几种Java堆OOM对应堆空间耗尽元空间OOM对应类元数据增长过快直接内存OOM对应NIO或Netty缓冲区设置过大还有一个GC overhead limit exceeded是GC反复回收却收不出空间时的保护机制。日常95%的OOM都能通过“堆转储业务代码审查”解决别一看到OOM就直接堆参数。5.3 Gradle构建中的JVM堆空间与JVM Options报错如果你用Gradle构建时遇到“Expiring daemon because JVM heap space is exhausted”本质上是Gradle守护进程的堆内存被占满Gradle会自动让旧daemon过期再启动新daemon。解决办法是在项目根目录的gradle.properties里调整守护进程参数org.gradle.jvmargs-Xmx2048m -XX:MaxMetaspaceSize512m这里要特别提醒Gradle守护进程是独立JVM它并不等于你的应用JVM。很多人给应用配了-Xmx4g结果构建还是崩因为Gradle daemon走的是gradle.properties里的org.gradle.jvmargs和应用启动脚本里的参数是两条线。还有一个容易踩的坑就是遇到“cannot collect jvm options caused by: 0: cannot read: d:v作业实训 vjetbrain_”这类报错。这个一般是Gradle或者IDE读取JVM options时配置文件里写了不合法路径或者Windows路径格式有问题。比如gradle.properties中的org.gradle.jvmargs出现引号缺失、路径带空格没转义或者IDEA的Gradle JVM选项里误填了不存在的目录。我的处理顺序是先看gradle.properties里有没有奇怪的jvmargs再检查IDEA设置里的Gradle JVM options是否指向正确路径最后去用户目录的.gradle/gradle.properties里搜索可疑配置。清理干净后重启IDE和Gradle daemon一般就能恢复。我自己长期在用的配置是这样org.gradle.jvmargs-Xmx2048m -Dfile.encodingUTF-8不要在配置里写中文目录也尽量不要用相对路径Windows下路径分隔符统一用正斜杠更省心。最后再分享一个小习惯我写任何Java服务启动脚本里都会固定带上-XX:HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath和GC日志参数看着麻烦但每次出现线上问题时这些日志都能帮我把故障时间线准确还原。内存结构这块内容看着偏概念但只要把每个区域各自能干什么、各自会出什么异常都理顺之后遇到再复杂的内存性能问题心里都会有个底。
