前段时间同事在群里发了一张线上报错截图日志里红字异常特别醒目java.lang.OutOfMemoryError: Java heap space。群里沉默了几秒紧接着有人问“这到底是堆满了还是内存泄漏”“JVM内存模型到底怎么画的来着”问题一出来发现平时CRUD写得很溜的几个人其实对JVM内存区域划分的概念是模糊的。这也不奇怪毕竟日常开发很少直接碰内存可一旦线上出问题或者面试被问到“JVM运行时数据区有哪些”能不能讲清楚就直接区分出你是“用过”还是“懂过”Java。这篇内容不是教科书式的复述而是结合我实际排查问题、调优参数、带新人时踩过的坑把JVM核心认知里最基础也最关键的内存区域划分讲透。你会搞清楚程序计数器、虚拟机栈、堆、方法区各管什么哪些区域会抛什么异常以及-Xmx、-Xss、-XX:MaxMetaspaceSize这些参数到底在设置什么。适合刚学JVM的同学也适合写了两三年Java但对内存管理始终一知半解的朋友。1. 为什么每个Java程序员都得懂内存区域划分1.1 一次线上OOM引起的重视继续说开头那个场景。报错的是我们一个订单同步服务平时跑得挺稳结果那天业务量一涨内存直接爆掉。重启以后好了但大家都清楚这只是暂时的。我当时让负责的同学先执行jstat -gcutil pid 1000看一眼GC情况结果他愣住了问我“这输出的E、S0、S1、O、M是什么意思”。那一刻我突然意识到很多人背过“堆、栈、方法区”这几个名词但真到用的时候连观察内存状态都不知道看哪个区域。那次事故最终定位到是一个大对象列表被缓存到了静态Map里没有清理策略导致老年代不停增长。修复并不复杂但排查过程绕了不少弯路。如果一开始就对内存区域划分有清晰认知知道“对象进了堆、老年代涨了说明有对象一直在逃逸”并且能对应上jstat每列的含义定位问题的时间至少能缩短一半。1.2 内存区域划分到底解决了什么问题很多人觉得Java有自动内存管理GC为什么还要手动关心内存区域这个想法其实有个误区GC只是帮你回收了堆和方法区里的部分垃圾但它不会帮你决定“一个对象应该放在哪”“栈帧多大够用”“类信息存哪儿”。你需要设置堆大小、栈大小、元空间大小需要理解对象什么时候能进入老年代、哪些线程私有的数据不会被其他线程访问——这些基础全建立在内存区域划分之上。换句话说内存区域划分就是JVM的“城市规划图”。懂得了这张图你才知道自己写的代码运行在哪个区域、参数配置影响的是哪块空间、报错信息对应的是哪个区域的异常。面试中那一整套“JVM工作原理”“GC回收器选择”“线程池参数配置”的追问追根溯源都逃不开这份区域划分的底子。2. 运行时数据区的整体架构2.1 线程私有与线程共享的分类逻辑JVM在执行Java程序时会把它管理的内存划分成若干个不同的数据区域。这些区域从“是否线程共享”的角度看天然分成两类线程私有的和线程共享的。为什么有些区域要线程私有你可以把每个线程想象成一个独立的“工人”每个工人干活时手里需要一张自己的操作台、一沓便签纸、一个进度记录本。这些工具如果大家混用你写一笔我画一下工作早就乱套了。所以程序计数器、虚拟机栈、本地方法栈这三个区域是每个线程独享的生命周期跟线程一致线程结束区域也释放。线程共享的区域则像是公司的公共仓库和公共档案室。所有线程都能往里存取对象、读取类信息。因为共享所以这些区域才会成为GC的重点关注对象也最容易出现并发访问和内存压力的问题。Java堆和方法区就承担了这个角色。2.2 一张表理清五个核心区域JVM规范中的运行时数据区主要包含五块程序计数器、虚拟机栈、本地方法栈、Java堆、方法区。先把它们的关键信息列成一张速查表后面再逐一展开讲。区域线程关系存储内容常见异常程序计数器线程私有当前线程执行的字节码行号指示器无虚拟机栈线程私有栈帧每个方法调用对应一个栈帧StackOverflowError、OutOfMemoryError本地方法栈线程私有为Native方法服务StackOverflowError、OutOfMemoryErrorJava堆线程共享对象实例、数组OutOfMemoryError: Java heap space方法区线程共享类信息、常量、静态变量、JIT缓存OutOfMemoryError: Metaspace我建议你先把这张表装进脑子里。后面每一次看GC日志、调JVM参数本质上都是在跟这张表里的各个区域打交道。3. 逐区拆解每个内存区域里到底装了什么3.1 程序计数器最不起眼但绝不能少程序计数器在五个区域里存在感最低因为它既不会OOM也不归GC管。但它做的事情非常关键记录当前线程正在执行的字节码指令地址。为什么要记录这个因为线程是会切换的。假设线程A执行到第10行指令时CPU被线程B抢走了等线程A再次被调度回来它得知道自己刚才执行到哪一行了。这个“继续往下执行的线索”就存在程序计数器里。如果当前执行的是Native方法程序计数器的值是undefined因为没有字节码指令可记录。程序计数器的空间很小可以理解成线程私有的一小块内存。它也是规范里唯一没有规定任何OutOfMemoryError情况的区域所以一般面试时能说出“它存的是字节码行号、线程私有、不会OOM”这三点就过关了。3.2 Java虚拟机栈方法调用的“便签纸”虚拟机栈描述的是Java方法执行的线程内存模型。每个线程的栈里装着若干个栈帧每调用一个方法就压入一个栈帧方法返回栈帧弹出。栈帧里主要包含局部变量表、操作数栈、动态链接、方法返回地址。栈帧组成主要作用局部变量表存放方法参数和方法内部定义的局部变量操作数栈存放计算过程中的中间结果字节码指令的操作对象动态链接指向运行时常量池中该方法的引用支持方法调用解析方法返回地址方法退出后恢复到调用位置所需的信息看到这里你应该明白了为什么递归没写终止条件最终会抛StackOverflowError——每一层递归都会压入一个栈帧而线程能拥有的栈帧数量是有限度的。默认情况下64位Linux和macOS上每个线程的栈大小是1MB用-Xss可以调整。给你一个更直观的理解假期你往书包里塞衣服塞到一定厚度就拉不上拉链了。栈帧就是那一层层衣服拉链就是栈的容量上限。想多塞一点就调大-Xss但调得过大也会占用过多内存挤占其他资源甚至导致系统能创建的线程数量变少。3.3 本地方法栈被合并的“编外区域”本地方法栈跟虚拟机栈的作用类似区别在于虚拟机栈为Java方法服务本地方法栈为Native方法服务。这里说的Native方法是指使用native关键字修饰、由C/C等非Java语言实现的方法。在HotSpot虚拟机里这块区域跟Java虚拟机栈被合并成了一个你设置-Xss时两个栈的大小都会受影响。实际开发中我们很少直接调用Native方法但你依赖的底层库可能一直在用比如一些网络库、加密库、文件IO操作在底层可能走了native实现。所以它虽然“编外”但依然线程私有依然可能抛StackOverflowError和OutOfMemoryError。3.4 Java堆所有对象的“仓库”Java堆是JVM内存区域里最大的一块也是GC工作的主战场。几乎所有的对象实例和数组都在这里分配。为什么加“几乎”因为随着JIT编译器和逃逸分析技术的发展如果确定一个对象不会逃逸出方法JVM可能会在栈上直接分配对象空间而不是进堆。不过这只是优化手段从逻辑上说堆依然是对象的主要存放地。堆在物理上可以被分成新生代和老年代两块比例上新生代又可以细分为Eden区和两个Survivor区。默认情况下Eden区和Survivor区的比例是8:1:1这个比例可以通过-XX:SurvivorRatio调整。这么说可能有点空洞来算笔账。假设你的服务设置了-Xms2g -Xmx2g -Xmn1g那么新对象诞生在Eden区Eden约800MB。每轮Minor GC后存活对象进入Survivor区。经历一定次数GC仍然存活的对象进入老年代。老年代默认是新生代的2倍大约2GB这里按整个堆2g、新生代1g推算老年代约1g。这组数字不用死记但你得理解为什么大对象直接进老年代因为大对象在Eden区频繁复制代价太高。为什么长期存活的对象要升入老年代因为老年代的GC频率更小更适合“寿星”居住。理解了这个你以后看GC日志里Eden Space、Survivor Space、Old Gen的状态变化就不会一脸懵了。3.5 方法区与运行时常量池类元数据的“档案室”方法区存储的是类信息、常量、静态变量、即时编译器编译后的代码缓存等。很多人会把方法区跟“永久代”混为一谈准确说永久代是HotSpot在JDK 8以前对方法区的一种实现方式JDK 8以后方法区被迁移到了本地内存里的元空间Metaspace。方法区里还有一个重要的组成部分叫运行时常量池它负责存放编译期生成的字面量比如字符串字面量、final常量值和符号引用。字符串常量池在JDK 7以前也在方法区里JDK 7开始被移到了Java堆。这也是为什么常量池的讨论总是容易把人绕晕的原因——因为它确实“搬家”过。方法区如果满了会抛OutOfMemoryError: Metaspace。常见的场景是运行时动态生成大量类比如某些框架做CGLIB代理、持续热部署加载新类而类加载器又无法正常回收元空间就会一路涨到物理内存不够用。4. 容易被忽略的“编外内存”直接内存与元空间4.1 直接内存为什么在JVM规范之外直接内存Direct Memory不在JVM规范规定的运行时数据区内但它经常参与Java程序的内存计算尤其是在使用NIO的DirectByteBuffer时。它的思路很直接在Java堆之外分配一块本地内存由操作系统直接管理。这样一来IO操作时数据可以少一次从Java堆复制到native内存的过程性能会好不少。代价是分配和回收直接内存不受Java堆GC的完全控制如果一直分配不释放它会吃掉操作系统的真实内存。相关的参数是-XX:MaxDirectMemorySize默认大约等于-Xmx的值。很多同学只盯着堆内存忽略了直接内存一旦程序用了大量NIO就可能出现明明堆剩余很多却报”Direct buffer memory“错误的情况。所以排查内存问题时别把眼光只放在堆上。4.2 永久代到元空间一次重要的迁移JDK 8把原本用永久代实现的方法区改成了元空间为什么这么改因为永久代的大小是固定的默认值有限经常出现类元数据过多导致的OutOfMemoryError: PermGen space而且调优也不方便。改成元空间以后最直观的变化是类的元数据不再占用Java堆内存而是使用本地内存。默认情况下元空间大小没有上限只受物理内存限制。你可以通过-XX:MetaspaceSize设定初始阈值用-XX:MaxMetaspaceSize设置最大值。实际效果就是使用Spring Boot、MyBatis、CGLIB这类动态代理重灾区的项目再也不用频繁担心PermGen爆掉了。但也不是说完全不用管如果应用出现“动态生成类停不下来”的问题元空间照样能涨满。我见过一个轮询生成代理类的测试代码跑一个晚上就把元空间撑爆了。5. 控制内存区域的JVM参数与调优工具5.1 内存参数配置速查了解了每个区域接下来就是通过参数控制它们。参数不用全背但下面这组是日常开发、排障、面试都绕不开的。参数作用我的建议-Xms初始堆大小建议与-Xmx一致避免堆反复伸缩带来的性能抖动-Xmx最大堆大小根据业务估算一般不超过物理内存的50%-70%-Xmn新生代大小可根据GC日志调整一般占堆大小的1/3到1/4-XX:SurvivorRatioEden与Survivor比例默认8通常不需要动-Xss线程栈大小一般是512KB-1MB不是越大越好-XX:MetaspaceSize元空间初始阈值可按应用类数量设置比如256MB-XX:MaxMetaspaceSize元空间最大大小建议设置避免无上限占用物理内存-XX:MaxDirectMemorySize直接内存上限用NIO时务必关注很多人设置堆内存的时候会陷入一个误区觉得-Xmx调得越大越好。其实堆太大GC单次STW的时间会变长堆太小GC频率会变高。比较靠谱的做法是先用默认参数跑一段时间再用jstat观察GC频率和内存占用最后反推合适的堆大小。5.2 常用调优工具怎么看区域内存很多工具都能帮助观察内存状态我们不用都精通但至少要会几个常用的。下面是我在实际工作中用得最多的几个附上它们解决什么问题。工具核心作用我常用的命令/操作jps查看Java进程PIDjps -ljstat查看GC和类加载情况jstat -gcutil pid 1000jmap查看堆配置、导出堆dumpjmap -heap pid、jmap -dump:formatb,fileheap.hprof pidjstack查看线程栈快照jstack pidjconsole图形化监控内存、线程、类直接启动连接进程即可visualvm可视化分析堆dump和GC导入.hprof文件查看对象占用Top Narthas在线诊断神器dashboard看全局memory看各区域内存池情况我第一次用arthas的memory命令时一眼就看到Eden区、老年代、元空间分别占了多少比在日志里猜直观太多了。如果是本地开发或者测试环境配合jconsole或visualvm观察对象分配和GC效果也很直观。6. 从内存区域划分到OOM排查实战6.1 各区域常见的异常形态不同区域OOM的报错信息不一样排查方向也不一样。这里把常见的异常形态整理成一张速查表看到报错先定位区域再说下一步。异常信息对应区域/原因排查方向Java heap space堆内存不足对象过多或泄漏用jmap导出堆分析对象引用链GC overhead limit exceededGC几乎不回收98%时间在GC且回收不到2%查看堆使用率是否持续高位考虑堆溢出或泄漏Metaspace元空间不足类元数据过多观察类加载数量是否持续增长检查类加载器是否泄漏unable to create new native thread无法创建新线程线程数超过操作系统限制检查线程池配置、操作系统ulimit限制StackOverflowError虚拟机栈溢出通常是递归过深用jstack查看栈调用定位无限递归Direct buffer memory直接内存不足检查NIO相关代码评估-XX:MaxDirectMemorySize6.2 一套排查思路三个真实场景排查内存问题时我建议按这个顺序来先用jps或top确认进程还在拿到PID。用jstat -gcutil pid 1000连续观察GC情况和各区占用判断是内存泄漏还是内存不足。用jmap -heap pid确认堆配置是否跟预期一致。必要时jmap -dump导出堆快照用visualvm或MAT分析大对象和引用链。如果怀疑线程问题用jstack抓线程栈。在线环境不方便重启时用arthas直接跑dashboard、memory、thread快速判断瓶颈。场景一有个报表服务跑了几天后响应变慢日志里频繁出现GC overhead limit exceeded。用jstat观察后发现老年代占用几乎打满导出堆快照分析发现一个HashMap里堆积了大量历史报表的查询条件对象根因是缓存Map没有设置过期策略。修复后老年代稳定在30%以下。场景二一个内部系统持续热部署后报Metaspace OOM。用jstat -class观察类加载数量发现每发布一次类数量就涨几百个而且旧类没有卸载。定位到是自定义类加载器持有静态引用依赖包重复加载导致的元空间泄漏。这个坑如果不从元空间的角度想很难想到。场景三新同学写了一段把菜单表转树的递归代码数据量一大直接StackOverflowError。用jstack抓到异常线程调用栈里几百行都是同一个方法一眼看出递归没有终止条件。改完之后树构建稳定CPU占用也降下来了。6.3 开发环境防OOMIDEA内存设置实操说到开发测试时的OOM还一个很常见的场景是IDEA自身卡顿、编译时OOM或者本地启动项目时频繁OOM。首先要区分两个东西本地IDEA的JVM内存和项目运行时的JVM内存这是两套设置。IDEA自己的内存在菜单Help里选择Edit Custom VM OptionsIDEA会为你创建一个idea.vmoptions文件里面可以设置-Xms和-Xmx。比如我的开发机是16GB内存会给IDEA设置为-Xms512m -Xmx2048m并在文件里加上-XX:HeapDumpOnOutOfMemoryError这样IDEA万一OOM还能留个dump文件排查。项目运行时的JVM参数则在Run/Debug Configurations里找到对应应用的VM options。本地开发一般建议给足内存比如-Xms512m -Xmx1024m -XX:MaxMetaspaceSize512m。如果你的项目跑起来总在本地OOM先别急着把-Xmx开到好几个G用jvisualvm本地连一下进程看看是不是哪块缓存没控制好或者测试数据量太大导致堆被打满。盲目加堆是治标不治本。另外补一个容易踩的坑很多人项目里用的是CGLIB动态代理、反射比较重的框架本地启动时如果报Metaspace相关错误优先检查-XX:MaxMetaspaceSize是不是设得太小了适当调大元空间而不是去动堆的-Xmx。我在实际排查中养成了一个习惯不管什么问题先看一眼各个内存区域的水位再动手调参。内存区域划分不是背完就扔的八股文而是每次看到GC日志、OOM报错、性能指标时能迅速在脑子里浮现出“是哪块区域出了状况”的地图。你把这幅地图刻进脑子里后面再接触G1、ZGC这些回收器理解起来就是顺水推舟的事。最后分享一个我常用的笨办法刚开始学JVM内存的时候我在本地开了一个Spring Boot应用先跑一分钟用jconsole截图看一眼各区水位再写一段往List里塞对象的代码观察Eden区的增长曲线。多来几次你就能直观感受到“对象先到Eden、GC后进Survivor、长期存活进入老年代”的完整过程。这种肉眼可见的反馈比单纯记概念牢固得多。