做Java开发这些年我面试过不少人也带过一些新人大家聊到“Java内存区域”时第一反应基本都是“这是面试八股文”背一背堆、栈、方法区就完事了。但说实话线上OOM、频繁Full GC、CPU飙高这些故障一旦出现最后拼的不是谁背得熟而是谁脑子里那张内存地图画得清楚。这篇文章我不会给你念JVM规范而是从实际排查的角度把Java内存区域底层的划分逻辑、对象生死判定、核心参数调优以及真实故障排查过程串起来。不管你是准备Java基础面试还是正在跟系统OOM死磕都应该能从里面拿到一些可以直接用的东西。1. 整体设计与思路拆解为什么要把内存分成一块一块1.1 先从“图书馆”说起把JVM内存想象成一个图书馆。书架堆放的是真正的内容对象实例前台登记表栈记录谁在借哪本书局部变量和方法调用图书分类卡方法区/元空间是用来查找书籍的索引信息类元数据、方法字节码。如果不分区域所有东西混在一起图书管理员垃圾回收器每次整理书架都要把整个馆翻一遍效率和正确性都无从谈起。所以JVM内存区域的设计本质上是两类问题的拆解按数据的生命周期管理让“短命”的数据和“长命”的数据各归其位避免一次全量扫描。按线程隔离与共享的粒度划分让私有数据无锁访问让共享数据统一管理。JVM规范把运行时数据区分成五个主要区域外加一个“额外”的直接内存堆外内存区域存储内容线程共享生命周期常见异常程序计数器当前线程执行字节码的行号指示器否随线程无规范中唯一无OOM区域虚拟机栈栈帧局部变量表、操作数栈、返回地址等否随线程StackOverflowError / OutOfMemoryError本地方法栈为native方法服务否随线程StackOverflowError / OutOfMemoryErrorJava堆对象实例、数组是随JVMOutOfMemoryError方法区元空间类元数据、运行时常量池、静态变量等是随JVMOutOfMemoryError直接内存NIO的DirectByteBuffer等是全局共享由显式回收OutOfMemoryError简单记的话栈管运行堆管存储方法区管结构。这三句话基本覆盖了80%的场景认知。1.2 为什么栈必须是线程私有的每个线程运行的本质是不断执行方法调用。每次方法调用都会产生一个栈帧压入线程自己的虚拟机栈中。方法结束了栈帧弹出对应的内存就释放了。这个“压栈弹栈”的操作完全由线程自己控制不需要垃圾回收器介入所以设计上根本不需要和其他线程共享。这也是栈上分配、逃逸分析这些优化能成立的基础。如果某个对象只在一个线程内部使用JIT编译器检测到它没有“逃逸”出当前作用域就可以直接在栈帧上分配内存方法结束即销毁连GC压力都省了。我在实际项目里碰到过极端小对象高频创建导致的GC频繁问题开启逃逸分析参数后吞吐量肉眼可见地提升。这就是理解内存区域划分之后能做出的调优决策。1.3 堆和元空间JVM的“仓库”与“索引室”堆是Java对象的老家几乎所有对象实例和数组都在这里分配。为了高效回收堆还被划分成新生代Eden、S0、S1和老年代这是带分代假说的经典设计——绝大多数对象朝生夕灭把短命对象集中放一起用复制算法清理少数熬过多轮回收的对象晋升到老年代用标记-整理/标记-清除算法处理。方法区在JDK 8之后从“永久代”变成了“元空间”最大区别是把字符串常量池挪到了堆里类元数据则使用本地内存Native Memory不再受限于JVM堆内存的上限。这对搞Java后端的人来说特别重要因为很多框架Spring、MyBatis加载的类特别多如果元空间上限设置太小启动就会直接OOM。2. 核心细节解析与实操要点对象是活是死由谁说了算2.1 引用计数法的陷阱很多人以为判断对象能不能回收很简单数一下引用数就行。引用计数法从0变成1就活着变成0就回收。但Java虚拟机主流实现并没有用这个方案原因大家应该也听过循环引用无法解决。A持有BB持有A外部已经没有引用指向它们了但它们俩的引用数不为0垃圾收集器无法回收。这就好比两个人互相担保借钱银行外面已经没人认识他们了但因为互相有担保关系银行始终觉得这笔账还有抵押物。结果就是内存一直被占用直到泄漏。2.2 可达性分析一切从GC Roots出发HotSpot VM用的正式方案是可达性分析。核心思想是定义一组“根对象”GC Roots从根出发沿着引用链遍历凡是能被引用链触碰到的对象就是“活的”否则就是“可回收的”。哪些对象能当GC Roots我用最常见的几个举个例子虚拟机栈中局部变量表引用的对象当前正在执行的方法里用到的局部变量方法区中静态属性引用的对象static修饰的变量方法区中常量引用的对象final修饰的常量引用JNINative方法引用的对象活跃线程对象、被synchronized锁住的对象等理解GC Roots最大的用处是排查内存泄漏。比如你在一个静态HashMap里存了一堆业务对象线程栈上早就没人引用它们了但从静态变量这条链走过去它们每个都能被触达于是GC一直认为它们是存活的。时间一长堆占用就悄悄涨上去最后整出OOM。这个问题我在后面故障排查部分会再展开。2.3 四个阶段的“死缓”流程一个对象真正从存活到被回收并不是一次标记就立刻动手。HotSpot里对象被判断为不可达后至少还会经历一两次“死缓”机会第一次标记可达性分析发现不处于GC Roots引用链上。筛选判断该对象是否重写了finalize()方法没有重写或已经调用过则直接回收。放入F-Queue重写了finalize()的对象会被放进一个低优先级队列由Finalizer线程执行。第二次标记Finalizer线程执行后如果对象重新让自己被引用比如把自己赋值给某个静态变量它就能“逃过一劫”否则彻底回收。我自己在实际工作中几乎不依赖finalize()来做资源清理因为它执行时机不确定还可能导致对象“死而复生”引发各种奇怪问题。了解这个流程主要是为了应对面试和排查“为什么这个对象迟迟没被回收”的疑问。2.4 别忽视栈上的“方法出口”内存讲内存区域时很多人只盯着堆其实栈帧里也有严重影响性能的东西比如局部变量表和操作数栈。局部变量表存放方法参数和方法内部定义的局部变量它的容量在编译期就确定了所以栈帧的内存大小也是编译期确定的。但操作数栈负责寄存字节码指令运算的中间结果容量同样在编译期确定。这意味着你在方法里声明了一堆大Map或者List时对象本身在堆里但引用在局部变量表里占着槽位。方法不结束这些引用一直存在即便那个对象已经没用了也不利于GC提前回收。所以有个实用的编码习惯不需要刻意把局部变量置为null现代JIT优化效果有限但要注意不要在一个长方法里用一个超大作用域的变量拖着大量对象的引用导致GC无法回收。把变量的作用域尽量缩小本质上就是配合栈帧的弹出时机让引用链尽早断开。3. 实操过程与核心环节实现用参数与工具重新认识内存布局3.1 从一张运行图看内存分布先写一段最基础的代码看看一个对象在内存里到底怎么流动public class MemoryDemo { // 静态变量属于GC Roots存储在元空间/堆中 private static User keepAlive new User(static-user); public static void main(String[] args) throws InterruptedException { // 局部变量引用存储在虚拟机栈局部变量表中 User localUser new User(local-user); // 让程序跑一会儿方便观察 Thread.sleep(30000); // 大量创建短命对象模拟新生代压力 for (int i 0; i Integer.MAX_VALUE; i) { User temp new User(temp- i); if (i % 100000 0) { Thread.sleep(10); } } } static class User { private String name; public User(String name) { this.name name; } } }运行的时候加上JVM参数java -Xms256m -Xmx256m -Xmn64m -XX:MetaspaceSize64m -XX:MaxMetaspaceSize128m -verbose:gc MemoryDemo几个参数解释一下-Xms256m -Xmx256m堆初始大小和最大大小。生产环境建议设成一样避免运行期扩容带来的停顿。-Xmn64m新生代大小。新生代剩余部分就给老年代。-XX:MetaspaceSize64m元空间初始大小。-verbose:gc把GC日志打到控制台。在程序sleep的30秒里用jcmd查看当前JVM内存情况jcmd pid GC.heap_info你会在输出里看到类似这样的信息PSYoungGen total 57344K, used 3072K ParOldGen total 65536K, used 1024K Metaspace used 4800K, capacity 5600K ...这时你会发现keepAlive这个静态引用的对象被留在老年代或堆的某一块区域而localUser只是栈帧里一个引用对象本身待在Eden区。这种直观对照比背十遍“堆里存对象栈里存引用”都要深刻。3.2 分代参数与对象晋升判定对象在新生代里每熬过一次Minor GC年龄加1默认到达15次后晋升到老年代。这个阈值可以通过-XX:MaxTenuringThreshold15调整。但我实际调优时很少修改这个参数而是优先关注Eden区大小和Survivor区比例。新生代里Eden和两个Survivor区的默认比例是8:1:1通过-XX:SurvivorRatio8控制。每轮Minor GC会把Eden和一个Survivor中的存活对象复制到另一个空的Survivor区。如果Survivor区放不下了就用分配担保机制直接把对象扔进老年代。我遇到过一种典型问题业务高峰期大量对象快速创建Eden区设得太小导致Minor GC异常频繁。每次GC都有大量对象要复制到SurvivorSurvivor放不下就只能进老年代。老年代涨得飞快最终引发Full GC。解决思路也很直接把Eden区调大降低GC频率同时保证Survivor有足够空间容纳存活对象。3.3 栈与元空间的核心参数栈大小默认在大多数64位Linux上是1MB通过-Xss256k可以调小。很多微服务应用里线程动辄几百上千每个线程1MB栈空间光栈就吃掉几百MB“隐形”内存。把这些线程栈调成256KB到512KB能省出非常多内存。但也不能无脑调小遇到递归深度大的算法栈太浅会直接StackOverflowError。元空间参数我在上线前一定会检查。-XX:MetaspaceSize是初始大小-XX:MaxMetaspaceSize是上限。如果只设MaxMetaspaceSize不设初始大小JVM启动时可能频繁触发类元数据空间扩容的Full GC。我习惯让两者保持一致比如都是256MB这样扩容GC发生的概率就低很多。关键参数速查表参数作用我常用的生产建议-Xms / -Xmx堆初始/最大大小两者一致预留系统内存30%-40%-Xmn新生代大小堆的1/3左右再观察实际GC日志微调-XX:SurvivorRatioEden/Survivor比例默认8大对象多时可调大Eden占比-Xss单线程栈大小普通微服务512k够用深度递归保留1m-XX:MetaspaceSize元空间初始大小根据启动后类加载量观察与Max一致-XX:MaxMetaspaceSize元空间上限普通Spring Boot项目256m-512m足够-XX:HeapDumpOnOutOfMemoryErrorOOM时自动dump堆线上必须开启-XX:HeapDumpPathdump文件路径预留足够磁盘空间写绝对路径3.4 用Arthas在线观察内存分布比起jcmd和jstat我日常用得最顺手的其实是Arthas。在命令行执行java -jar arthas-boot.jar然后选择目标Java进程进入dashboard界面就能实时看到heap、non-heap、eden、survivor、old、metaspace的使用情况。命令memory可以精确输出不同类型内存区域的使用量。这是排查线上问题时最直观的入口。4. 常见问题与排查技巧实录从OOM到内存泄漏的真实战场4.1 看一眼就出答案堆内存溢出java.lang.OutOfMemoryError: Java heap space堆OOM是线上遇到最多的内存故障。出现堆OOM时先不要慌着重启按下面顺序做一遍查看GC日志确认是“对象创建太多太快”还是“对象堆积无法回收”。用jstat -gcutil pid 1000连续观察看Eden区和老年代的变化趋势。如果老年代持续增长且GC后下降不明显说明存在内存泄漏或者缓存类对象过多。用jmap -dump:live,formatb,file/tmp/heap.hprof pid导出堆快照注意会影响性能尽量在低峰期。用MAT或VisualVM分析Dominator Tree揪出占用内存最大的对象和它的引用链。这有个非常经典的坑要提醒导出heap dump前如果加了-dump:live会先触发一次Full GCdump出来的堆保底只包含存活对象但就是这次Full GC会把现场“洗一遍”。如果排查目标是找“为什么GC回收不掉”的问题应该不加live导出如果只想看存活对象的大头才加live。4.2 元空间OOMNoClassDefFoundError的真相热搜词里有个高频错误java.lang.NoClassDefFoundError: java/applet/Applet。这类错误表面上和内存区域没关系但很多人被它折磨过。它的出现通常有两种可能类加载阶段依赖的类在编译期存在运行期却缺失比如JDK模块变化、classpath不完整。元空间不足类加载器加载新类失败。如果是第二种老年代方法区相关的日志里会看到OutOfMemoryError: Metaspace。这时要么调大-XX:MaxMetaspaceSize要么排查类加载器是否泄漏。我遇到过一个场景Tomcat热部署多次后元空间持续上涨因为每个应用被多次重新部署时旧类加载器没有被完全释放。解决思路是控制热部署次数或者定期重启实例释放类加载器。4.3 栈溢出StackOverflowError与线程数极限递归没有出口、或者方法调用层级太深都会触发StackOverflowError。这类错误本身好排查栈输出会清清楚楚打印出调用链。真正麻烦的是“线程数耗尽”引起的OutOfMemoryError: unable to create new native thread。这个问题的根源不只是栈大小还牵扯到操作系统线程数量和进程虚拟内存限制。我在Linux服务器上处理过一个高频发版场景应用线程数被拉到几千超过了/etc/security/limits.conf中的nproc限制。最终调整了系统线程数上限同时把线程池核心线程数收缩才算解决问题。注意排查线程问题时jstack pid找到线程DUMP重点看大量WAITING状态下的线程是在等锁还是等任务。如果是等任务通常是线程池队列设置不合理而不是内存问题。4.4 数组越界与内存区域的隐秘联系热搜词里“java中数组越界异常”ArrayIndexOutOfBoundsException在JVM层面也有意思。数组对象在堆里是连续内存分配JVM用arr.length记录数组长度每次访问都会做边界检查。如果频繁出现数组越界说明业务逻辑对集合长度预估有问题但底层其实还有一个常被忽视的点过大的数组会直接分配到老年代甚至触发OOM。创建数组时JVM会先计算对象头、数组长度记录、对齐填充等元素然后判断总大小是否超过TLABThread Local Allocation Buffer线程本地分配缓冲区剩余空间。如果数组太大直接走堆中老年代分配路径。这会导致老年代在没有对象晋升的情况下就出现大对象占用触发提前Full GC。排查这个问题可以打开GC日志看是否存在明显的老年代空间分配Pretenured或大对象分配日志。业务侧通常要做的是把大数组改成批量分页处理而不是一次全量加载。4.5 排查清单速查表现象优先怀疑的内存区域第一排查命令首选处置建议Java heap space堆jstat -gcutildump堆快照分析大对象Metaspace方法区/元空间jcmd GC.heap_info检查类加载器数量调大MaxMetaspaceSizeunable to create native thread虚拟机栈系统限制查看进程线程数和系统ulimit调小-Xss收缩线程池StackOverflowError虚拟机栈分析异常调用栈优化递归为循环增加栈大小GC频率明显偏高堆内新生代GC日志GCViewer调整分代比例优化对象创建NoClassDefFoundError方法区类加载器查看类加载日志检查依赖是否完整排查热部署场景4.6 我踩过的“内存泄漏不一定是堆”的坑有一次线上某个服务内存占用持续上涨堆内存看起来回收正常GC日志也漂亮得很但进程的RSS物理内存一路走高最后被linux OOM Killer杀掉。当时很困惑堆不涨内存去哪了后来一查发现是NIO使用堆外内存Direct Memory时DirectByteBuffer对象虽然很小但它引用着堆外的内存块。堆内的DirectByteBuffer可以被GC回收但如果回收不及时堆外内存就一直被占着却不归还操作系统。这类问题的排查工具是jcmd pid VM.native_memory需要开启-XX:NativeMemoryTrackingsummary。最终解决方式是给Netty的堆外内存池设置合理上限、关闭调试态下不必要的ByteBuf池化同时定期观察系统内存。这个案例提醒我Java内存区域的地图要扩展到进程级。JVM自己管理的堆内存只是应用内存的一部分元空间、线程栈、JIT编译器缓存、GC数据结构、堆外内存和JNI引用的Native内存加起来才是整个Java进程的完整内存账本。不懂这个线上排查内存问题相当于拿着半张地图找路。写在最后的一个实用技巧如果只让我推荐一个“投入产出比最高”的排查习惯那就是保证线上JVM必须带上OOM自动导出heap dump的启动参数。很多公司怕dump文件太大影响磁盘宁可让现场丢失也不开这个开关。但一次OOM发生之后如果没有dump文件排查思路基本靠猜。磁盘贵但是一次内存故障定位成本的百分之一都不到。这个参数带来的收益绝对超出你的预期。
做Java开发这些年我面试过不少人也带过一些新人大家聊到“Java内存区域”时第一反应基本都是“这是面试八股文”背一背堆、栈、方法区就完事了。但说实话线上OOM、频繁Full GC、CPU飙高这些故障一旦出现最后拼的不是谁背得熟而是谁脑子里那张内存地图画得清楚。这篇文章我不会给你念JVM规范而是从实际排查的角度把Java内存区域底层的划分逻辑、对象生死判定、核心参数调优以及真实故障排查过程串起来。不管你是准备Java基础面试还是正在跟系统OOM死磕都应该能从里面拿到一些可以直接用的东西。1. 整体设计与思路拆解为什么要把内存分成一块一块1.1 先从“图书馆”说起把JVM内存想象成一个图书馆。书架堆放的是真正的内容对象实例前台登记表栈记录谁在借哪本书局部变量和方法调用图书分类卡方法区/元空间是用来查找书籍的索引信息类元数据、方法字节码。如果不分区域所有东西混在一起图书管理员垃圾回收器每次整理书架都要把整个馆翻一遍效率和正确性都无从谈起。所以JVM内存区域的设计本质上是两类问题的拆解按数据的生命周期管理让“短命”的数据和“长命”的数据各归其位避免一次全量扫描。按线程隔离与共享的粒度划分让私有数据无锁访问让共享数据统一管理。JVM规范把运行时数据区分成五个主要区域外加一个“额外”的直接内存堆外内存区域存储内容线程共享生命周期常见异常程序计数器当前线程执行字节码的行号指示器否随线程无规范中唯一无OOM区域虚拟机栈栈帧局部变量表、操作数栈、返回地址等否随线程StackOverflowError / OutOfMemoryError本地方法栈为native方法服务否随线程StackOverflowError / OutOfMemoryErrorJava堆对象实例、数组是随JVMOutOfMemoryError方法区元空间类元数据、运行时常量池、静态变量等是随JVMOutOfMemoryError直接内存NIO的DirectByteBuffer等是全局共享由显式回收OutOfMemoryError简单记的话栈管运行堆管存储方法区管结构。这三句话基本覆盖了80%的场景认知。1.2 为什么栈必须是线程私有的每个线程运行的本质是不断执行方法调用。每次方法调用都会产生一个栈帧压入线程自己的虚拟机栈中。方法结束了栈帧弹出对应的内存就释放了。这个“压栈弹栈”的操作完全由线程自己控制不需要垃圾回收器介入所以设计上根本不需要和其他线程共享。这也是栈上分配、逃逸分析这些优化能成立的基础。如果某个对象只在一个线程内部使用JIT编译器检测到它没有“逃逸”出当前作用域就可以直接在栈帧上分配内存方法结束即销毁连GC压力都省了。我在实际项目里碰到过极端小对象高频创建导致的GC频繁问题开启逃逸分析参数后吞吐量肉眼可见地提升。这就是理解内存区域划分之后能做出的调优决策。1.3 堆和元空间JVM的“仓库”与“索引室”堆是Java对象的老家几乎所有对象实例和数组都在这里分配。为了高效回收堆还被划分成新生代Eden、S0、S1和老年代这是带分代假说的经典设计——绝大多数对象朝生夕灭把短命对象集中放一起用复制算法清理少数熬过多轮回收的对象晋升到老年代用标记-整理/标记-清除算法处理。方法区在JDK 8之后从“永久代”变成了“元空间”最大区别是把字符串常量池挪到了堆里类元数据则使用本地内存Native Memory不再受限于JVM堆内存的上限。这对搞Java后端的人来说特别重要因为很多框架Spring、MyBatis加载的类特别多如果元空间上限设置太小启动就会直接OOM。2. 核心细节解析与实操要点对象是活是死由谁说了算2.1 引用计数法的陷阱很多人以为判断对象能不能回收很简单数一下引用数就行。引用计数法从0变成1就活着变成0就回收。但Java虚拟机主流实现并没有用这个方案原因大家应该也听过循环引用无法解决。A持有BB持有A外部已经没有引用指向它们了但它们俩的引用数不为0垃圾收集器无法回收。这就好比两个人互相担保借钱银行外面已经没人认识他们了但因为互相有担保关系银行始终觉得这笔账还有抵押物。结果就是内存一直被占用直到泄漏。2.2 可达性分析一切从GC Roots出发HotSpot VM用的正式方案是可达性分析。核心思想是定义一组“根对象”GC Roots从根出发沿着引用链遍历凡是能被引用链触碰到的对象就是“活的”否则就是“可回收的”。哪些对象能当GC Roots我用最常见的几个举个例子虚拟机栈中局部变量表引用的对象当前正在执行的方法里用到的局部变量方法区中静态属性引用的对象static修饰的变量方法区中常量引用的对象final修饰的常量引用JNINative方法引用的对象活跃线程对象、被synchronized锁住的对象等理解GC Roots最大的用处是排查内存泄漏。比如你在一个静态HashMap里存了一堆业务对象线程栈上早就没人引用它们了但从静态变量这条链走过去它们每个都能被触达于是GC一直认为它们是存活的。时间一长堆占用就悄悄涨上去最后整出OOM。这个问题我在后面故障排查部分会再展开。2.3 四个阶段的“死缓”流程一个对象真正从存活到被回收并不是一次标记就立刻动手。HotSpot里对象被判断为不可达后至少还会经历一两次“死缓”机会第一次标记可达性分析发现不处于GC Roots引用链上。筛选判断该对象是否重写了finalize()方法没有重写或已经调用过则直接回收。放入F-Queue重写了finalize()的对象会被放进一个低优先级队列由Finalizer线程执行。第二次标记Finalizer线程执行后如果对象重新让自己被引用比如把自己赋值给某个静态变量它就能“逃过一劫”否则彻底回收。我自己在实际工作中几乎不依赖finalize()来做资源清理因为它执行时机不确定还可能导致对象“死而复生”引发各种奇怪问题。了解这个流程主要是为了应对面试和排查“为什么这个对象迟迟没被回收”的疑问。2.4 别忽视栈上的“方法出口”内存讲内存区域时很多人只盯着堆其实栈帧里也有严重影响性能的东西比如局部变量表和操作数栈。局部变量表存放方法参数和方法内部定义的局部变量它的容量在编译期就确定了所以栈帧的内存大小也是编译期确定的。但操作数栈负责寄存字节码指令运算的中间结果容量同样在编译期确定。这意味着你在方法里声明了一堆大Map或者List时对象本身在堆里但引用在局部变量表里占着槽位。方法不结束这些引用一直存在即便那个对象已经没用了也不利于GC提前回收。所以有个实用的编码习惯不需要刻意把局部变量置为null现代JIT优化效果有限但要注意不要在一个长方法里用一个超大作用域的变量拖着大量对象的引用导致GC无法回收。把变量的作用域尽量缩小本质上就是配合栈帧的弹出时机让引用链尽早断开。3. 实操过程与核心环节实现用参数与工具重新认识内存布局3.1 从一张运行图看内存分布先写一段最基础的代码看看一个对象在内存里到底怎么流动public class MemoryDemo { // 静态变量属于GC Roots存储在元空间/堆中 private static User keepAlive new User(static-user); public static void main(String[] args) throws InterruptedException { // 局部变量引用存储在虚拟机栈局部变量表中 User localUser new User(local-user); // 让程序跑一会儿方便观察 Thread.sleep(30000); // 大量创建短命对象模拟新生代压力 for (int i 0; i Integer.MAX_VALUE; i) { User temp new User(temp- i); if (i % 100000 0) { Thread.sleep(10); } } } static class User { private String name; public User(String name) { this.name name; } } }运行的时候加上JVM参数java -Xms256m -Xmx256m -Xmn64m -XX:MetaspaceSize64m -XX:MaxMetaspaceSize128m -verbose:gc MemoryDemo几个参数解释一下-Xms256m -Xmx256m堆初始大小和最大大小。生产环境建议设成一样避免运行期扩容带来的停顿。-Xmn64m新生代大小。新生代剩余部分就给老年代。-XX:MetaspaceSize64m元空间初始大小。-verbose:gc把GC日志打到控制台。在程序sleep的30秒里用jcmd查看当前JVM内存情况jcmd pid GC.heap_info你会在输出里看到类似这样的信息PSYoungGen total 57344K, used 3072K ParOldGen total 65536K, used 1024K Metaspace used 4800K, capacity 5600K ...这时你会发现keepAlive这个静态引用的对象被留在老年代或堆的某一块区域而localUser只是栈帧里一个引用对象本身待在Eden区。这种直观对照比背十遍“堆里存对象栈里存引用”都要深刻。3.2 分代参数与对象晋升判定对象在新生代里每熬过一次Minor GC年龄加1默认到达15次后晋升到老年代。这个阈值可以通过-XX:MaxTenuringThreshold15调整。但我实际调优时很少修改这个参数而是优先关注Eden区大小和Survivor区比例。新生代里Eden和两个Survivor区的默认比例是8:1:1通过-XX:SurvivorRatio8控制。每轮Minor GC会把Eden和一个Survivor中的存活对象复制到另一个空的Survivor区。如果Survivor区放不下了就用分配担保机制直接把对象扔进老年代。我遇到过一种典型问题业务高峰期大量对象快速创建Eden区设得太小导致Minor GC异常频繁。每次GC都有大量对象要复制到SurvivorSurvivor放不下就只能进老年代。老年代涨得飞快最终引发Full GC。解决思路也很直接把Eden区调大降低GC频率同时保证Survivor有足够空间容纳存活对象。3.3 栈与元空间的核心参数栈大小默认在大多数64位Linux上是1MB通过-Xss256k可以调小。很多微服务应用里线程动辄几百上千每个线程1MB栈空间光栈就吃掉几百MB“隐形”内存。把这些线程栈调成256KB到512KB能省出非常多内存。但也不能无脑调小遇到递归深度大的算法栈太浅会直接StackOverflowError。元空间参数我在上线前一定会检查。-XX:MetaspaceSize是初始大小-XX:MaxMetaspaceSize是上限。如果只设MaxMetaspaceSize不设初始大小JVM启动时可能频繁触发类元数据空间扩容的Full GC。我习惯让两者保持一致比如都是256MB这样扩容GC发生的概率就低很多。关键参数速查表参数作用我常用的生产建议-Xms / -Xmx堆初始/最大大小两者一致预留系统内存30%-40%-Xmn新生代大小堆的1/3左右再观察实际GC日志微调-XX:SurvivorRatioEden/Survivor比例默认8大对象多时可调大Eden占比-Xss单线程栈大小普通微服务512k够用深度递归保留1m-XX:MetaspaceSize元空间初始大小根据启动后类加载量观察与Max一致-XX:MaxMetaspaceSize元空间上限普通Spring Boot项目256m-512m足够-XX:HeapDumpOnOutOfMemoryErrorOOM时自动dump堆线上必须开启-XX:HeapDumpPathdump文件路径预留足够磁盘空间写绝对路径3.4 用Arthas在线观察内存分布比起jcmd和jstat我日常用得最顺手的其实是Arthas。在命令行执行java -jar arthas-boot.jar然后选择目标Java进程进入dashboard界面就能实时看到heap、non-heap、eden、survivor、old、metaspace的使用情况。命令memory可以精确输出不同类型内存区域的使用量。这是排查线上问题时最直观的入口。4. 常见问题与排查技巧实录从OOM到内存泄漏的真实战场4.1 看一眼就出答案堆内存溢出java.lang.OutOfMemoryError: Java heap space堆OOM是线上遇到最多的内存故障。出现堆OOM时先不要慌着重启按下面顺序做一遍查看GC日志确认是“对象创建太多太快”还是“对象堆积无法回收”。用jstat -gcutil pid 1000连续观察看Eden区和老年代的变化趋势。如果老年代持续增长且GC后下降不明显说明存在内存泄漏或者缓存类对象过多。用jmap -dump:live,formatb,file/tmp/heap.hprof pid导出堆快照注意会影响性能尽量在低峰期。用MAT或VisualVM分析Dominator Tree揪出占用内存最大的对象和它的引用链。这有个非常经典的坑要提醒导出heap dump前如果加了-dump:live会先触发一次Full GCdump出来的堆保底只包含存活对象但就是这次Full GC会把现场“洗一遍”。如果排查目标是找“为什么GC回收不掉”的问题应该不加live导出如果只想看存活对象的大头才加live。4.2 元空间OOMNoClassDefFoundError的真相热搜词里有个高频错误java.lang.NoClassDefFoundError: java/applet/Applet。这类错误表面上和内存区域没关系但很多人被它折磨过。它的出现通常有两种可能类加载阶段依赖的类在编译期存在运行期却缺失比如JDK模块变化、classpath不完整。元空间不足类加载器加载新类失败。如果是第二种老年代方法区相关的日志里会看到OutOfMemoryError: Metaspace。这时要么调大-XX:MaxMetaspaceSize要么排查类加载器是否泄漏。我遇到过一个场景Tomcat热部署多次后元空间持续上涨因为每个应用被多次重新部署时旧类加载器没有被完全释放。解决思路是控制热部署次数或者定期重启实例释放类加载器。4.3 栈溢出StackOverflowError与线程数极限递归没有出口、或者方法调用层级太深都会触发StackOverflowError。这类错误本身好排查栈输出会清清楚楚打印出调用链。真正麻烦的是“线程数耗尽”引起的OutOfMemoryError: unable to create new native thread。这个问题的根源不只是栈大小还牵扯到操作系统线程数量和进程虚拟内存限制。我在Linux服务器上处理过一个高频发版场景应用线程数被拉到几千超过了/etc/security/limits.conf中的nproc限制。最终调整了系统线程数上限同时把线程池核心线程数收缩才算解决问题。注意排查线程问题时jstack pid找到线程DUMP重点看大量WAITING状态下的线程是在等锁还是等任务。如果是等任务通常是线程池队列设置不合理而不是内存问题。4.4 数组越界与内存区域的隐秘联系热搜词里“java中数组越界异常”ArrayIndexOutOfBoundsException在JVM层面也有意思。数组对象在堆里是连续内存分配JVM用arr.length记录数组长度每次访问都会做边界检查。如果频繁出现数组越界说明业务逻辑对集合长度预估有问题但底层其实还有一个常被忽视的点过大的数组会直接分配到老年代甚至触发OOM。创建数组时JVM会先计算对象头、数组长度记录、对齐填充等元素然后判断总大小是否超过TLABThread Local Allocation Buffer线程本地分配缓冲区剩余空间。如果数组太大直接走堆中老年代分配路径。这会导致老年代在没有对象晋升的情况下就出现大对象占用触发提前Full GC。排查这个问题可以打开GC日志看是否存在明显的老年代空间分配Pretenured或大对象分配日志。业务侧通常要做的是把大数组改成批量分页处理而不是一次全量加载。4.5 排查清单速查表现象优先怀疑的内存区域第一排查命令首选处置建议Java heap space堆jstat -gcutildump堆快照分析大对象Metaspace方法区/元空间jcmd GC.heap_info检查类加载器数量调大MaxMetaspaceSizeunable to create native thread虚拟机栈系统限制查看进程线程数和系统ulimit调小-Xss收缩线程池StackOverflowError虚拟机栈分析异常调用栈优化递归为循环增加栈大小GC频率明显偏高堆内新生代GC日志GCViewer调整分代比例优化对象创建NoClassDefFoundError方法区类加载器查看类加载日志检查依赖是否完整排查热部署场景4.6 我踩过的“内存泄漏不一定是堆”的坑有一次线上某个服务内存占用持续上涨堆内存看起来回收正常GC日志也漂亮得很但进程的RSS物理内存一路走高最后被linux OOM Killer杀掉。当时很困惑堆不涨内存去哪了后来一查发现是NIO使用堆外内存Direct Memory时DirectByteBuffer对象虽然很小但它引用着堆外的内存块。堆内的DirectByteBuffer可以被GC回收但如果回收不及时堆外内存就一直被占着却不归还操作系统。这类问题的排查工具是jcmd pid VM.native_memory需要开启-XX:NativeMemoryTrackingsummary。最终解决方式是给Netty的堆外内存池设置合理上限、关闭调试态下不必要的ByteBuf池化同时定期观察系统内存。这个案例提醒我Java内存区域的地图要扩展到进程级。JVM自己管理的堆内存只是应用内存的一部分元空间、线程栈、JIT编译器缓存、GC数据结构、堆外内存和JNI引用的Native内存加起来才是整个Java进程的完整内存账本。不懂这个线上排查内存问题相当于拿着半张地图找路。写在最后的一个实用技巧如果只让我推荐一个“投入产出比最高”的排查习惯那就是保证线上JVM必须带上OOM自动导出heap dump的启动参数。很多公司怕dump文件太大影响磁盘宁可让现场丢失也不开这个开关。但一次OOM发生之后如果没有dump文件排查思路基本靠猜。磁盘贵但是一次内存故障定位成本的百分之一都不到。这个参数带来的收益绝对超出你的预期。
