JVM内存分配与垃圾回收全解：从对象生死到OOM排查实战

凌晨两点，你的手机响了——线上服务又OOM了。这已经不是第一次了，上次是凌晨三点，上上次是半夜十二点半。C++程序员看着你笑："指针全交给你们了还不够吗？"你默默打开JVM参数清单，开始检查堆内存设置。

说真的，Java开发者都欠JVM一笔账。我们每天new对象、调接口、写业务，从来不想这个对象到底被分配到了哪里，什么时候被回收。直到线上告警打过来，才发现自己对内存的理解停留在"堆和栈"两个词上。这篇博客就是想把Java内存分配与回收这件事彻底讲透，从运行时数据区划分、对象分配全过程，到垃圾回收的底层算法、主流收集器的选型，再到OOM的排查实战，一条线拉通。不管你是准备面试、还是正在调线上服务，都可以直接参考。

1. 内存区域拆解：Java到底把内存分成了几块

先说整体。JVM在运行Java程序时，会把自己管理的内存划分为若干个区域，各司其职。这些区域有些是线程共享的，有些是线程私有的，理解清楚每个区域的职责，是后面所有调优和排查的基础。

1.1 堆：所有对象的老家

堆是Java内存中最大的一块，也是垃圾回收的主战场。几乎所有对象实例都在这里分配。堆被划分为新生代和老年代，新生代又细分为Eden区、From Survivor区、To Survivor区，默认比例是8:1:1。为什么要分成这些区域，后面讲对象分配流程的时候会详细说。

从实践角度来看，堆大小的设置直接影响系统稳定性。设置得太小，对象分配不出去，直接OOM；设置得太大，GC停顿时间会变长，响应延迟上不去。这里面有个平衡的艺术，没有绝对正确的数值，只有适合当前场景的配置。

1.2 虚拟机栈：线程私有的执行空间

虚拟机栈描述的是Java方法执行的线程内存模型，每个方法执行时都会创建一个栈帧，栈帧里存放局部变量表、操作数栈、动态链接、方法出口等数据。说白了，你每调用一个方法，就会在栈上压入一个栈帧，方法执行完，栈帧弹出。

这个区域比较有意思的一个点是，栈深度的限制。默认情况下，线程栈大小是1MB左右（不同系统、不同JVM版本有差异），如果递归调用层数太深，没等堆内存耗尽，栈先溢出了，抛StackOverflowError。这就是为什么我们经常说递归要谨慎使用，能用迭代解决的尽量不要递归。

1.3 方法区与元空间：类的元数据放哪里

方法区存储的是已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等。在JDK 8之前，方法区的实现叫永久代，JDK 8之后被彻底移除，取而代之的是元空间。

这里有个非常重要的变化：永久代时期，方法区的大小是可以通过-XX:MaxPermSize控制的，而且它本身就在堆内，会受堆大小的制约。而元空间使用的不是JVM堆内存，而是本地内存，理论上只受本机物理内存总大小的限制。这个改动直接解决了一大类问题——之前经常遇到的java.lang.OutOfMemoryError: PermGen space在JDK 8以后基本消失了，取而代之的是Metaspace相关的OOM，但后者出现的概率低很多，因为你只需要关注元空间的默认上限。

1.4 程序计数器和本地方法栈：两个容易被忽略的角色

程序计数器是当前线程所执行的字节码的行号指示器。它是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域，线程私有。它的存在是为了线程切换后能恢复到正确的执行位置。

本地方法栈是给native方法服务的，HotSpot虚拟机直接把本地方法栈和虚拟机栈合并成了一个，所以用HotSpot开发时，不需要额外关心这个区域。但面试被问到你还是要能说出来它的定位。

1.5 直接内存：堆外内存的隐性占位

直接内存不是JVM运行时数据区的一部分，但Java NIO里的DirectByteBuffer可以直接分配堆外内存，这块内存不受JVM堆大小限制，只受本机物理内存限制。很多高性能框架如Netty就是靠它做零拷贝的。

排查线上内存问题的时候，直接内存是最容易被忽视的地方。你的堆设置很合理，GC也没有问题，但机器物理内存就是持续飙升，最后莫名其妙进程被系统杀掉。这种情况八九不离十是堆外内存泄漏了。所以排查内存问题的时候，除了堆转储，一定也要去看直接内存的使用情况。

2. 对象的一生：从new到被回收的完整路线图

理解了内存区域划分，接下来看一个对象从创建到销毁到底经历了什么。很多人以为new出来的东西往堆里一放就完事了，实际上JVM为了保证分配效率、控制GC停顿，在对象分配这件事上做了大量优化。

2.1 一个对象是如何分配出去的

假设你的代码里写了一行User user = new User();。JVM拿到这条指令后，会经历这么几步：

• 第一步，检查User类是否已经被加载、解析、初始化过，如果没有，先执行类加载过程。
• 第二步，为对象分配内存。对象所需内存大小在类加载完成之后就可以完全确定，分配方式有两种——指针碰撞（Bump The Pointer）和空闲列表（Free List）。堆内存规整的情况下用指针碰撞，只需要把指针往空闲方向挪动一段与对象大小相等的距离；不规整的情况下用空闲列表，JVM维护一个列表记录哪些内存块是可用的，分配时找一块足够大的划分给对象实例。
• 第三步，把分配到的内存空间初始化为零值（不包括对象头），这样对象的实例字段不赋初值也能直接使用，因为它们是零值。
• 第四步，JVM对对象头进行必要设置，包括这个对象是哪个类的实例、对象的哈希码、对象的GC分代年龄等信息。
• 第五步，执行<init>方法，按照代码中的初始化逻辑设置字段的初始值。

这整个流程背后有个问题：在并发环境下，多个线程可能同时分配对象，指针碰撞就冲突了。JVM用了两个方案解决，一个是CAS加失败重试保证更新操作的原子性，另一个就是下面的TLAB方案。

2.2 TLAB：线程本地分配缓冲区

TLAB（Thread Local Allocation Buffer）是JVM在Eden区为每个线程划分的一块私有缓冲区。对象分配时，线程优先在自己的TLAB里分配，TLAB用完或者对象太大放不下时，才去共享的Eden区域分配。

这样做有什么好处？想一下如果没有TLAB，每次分配对象都要保证线程安全，CAS操作是有开销的。有了TLAB之后，大部分小对象的分配都是线程私有的，不需要同步，分配效率大幅提升。你可以通过-XX:UseTLAB开启，-XX:TLABSize设置TLAB大小。

这里有个实际经验：如果线上系统创建的线程非常多、每个线程创建的对象又很多，TLAB太小会导致频繁的TLAB重分配，反而影响性能。但手动调整TLAB大小是个精细活，没有性能压测数据支撑，不要乱动。

2.3 新生代到老年代：对象是怎么"晋升"的

大部分对象都在Eden区出生，经过垃圾回收后，存活下来的对象会被移动到Survivor区。当对象在Survivor区熬过了一定次数的Minor GC（默认15次），就会被晋升到老年代。每次GC后对象的年龄加1，这个年龄记录在对象头里。

但晋升不只靠年龄这一条路，有几种特殊情况：

• 大对象直接进入老年代。可以通过-XX:PretenureSizeThreshold设置一个阈值，超过这个大小的对象直接在老年代分配。这样做是为了避免大对象在Eden和Survivor区之间反复复制，消耗大量内存空间。但要注意这个参数只对Serial和ParNew收集器有效。
• 动态年龄判定。JVM并不强制要求对象年龄达到15才晋升，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等满15次GC。
• 空间分配担保。进行Minor GC前，JVM会检查老年代最大可用的连续空间是否大于新生代所有对象总空间。如果大于，Minor GC是安全的；如果不大于，就检查HandlePromotionFailure设置，看是否允许担保失败。如果允许，继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于就尝试Minor GC，否则改为Full GC。

2.4 Minor GC、Major GC与Full GC

这三个概念面试必问，我见过好几个人把Major GC和Full GC混为一谈。简单来说：

• Minor GC清理新生代，频率高、速度快。
• Major GC清理老年代，通常伴随Minor GC。
• Full GC清理整个堆，包括新生代、老年代和元空间。Full GC的成本最高，停顿时间最长，是调优时最想避免的事情。

触发Full GC的常见原因包括：老年代空间不足、元空间空间不足、System.gc()被显式调用（虽然它只是一个建议，但很多情况下JVM真的会执行Full GC）、CMS的Concurrent Mode Failure等。线上环境的Full GC次数是需要重点监控的指标，如果频繁出现，系统响应时间一定会出现明显波动。

3. 垃圾回收的底牌：对象生死是怎样判定的

垃圾回收要做的第一件事是判断哪些对象是垃圾。这看起来很简单，实际上是个非常严谨的问题。判断对象是否存活，主流方案是可达性分析，但在早期，JVM也用过引用计数法。

3.1 引用计数法：简单但不靠谱

引用计数法的思路是给对象添加一个引用计数器，每当有一个地方引用它，计数器加1；引用失效，计数器减1；计数器为0的对象就是垃圾可以回收了。实现简单、判定高效，但它有个致命缺陷——无法解决循环引用问题。假设对象A引用了B，B也引用了A，除此之外这两个对象没有其他任何引用。它们的引用计数器永远不为0，但它们在逻辑上已经是死对象了。这套方案被主流JVM抛弃了。

3.2 可达性分析：从GC Roots出发

现在的HotSpot虚拟机用的是可达性分析算法。思路是从一组称为"GC Roots"的根对象出发，通过引用链向下搜索，搜索过程中走过的路径称为Reference Chain。如果一个对象到GC Roots没有任何引用链相连，说明这个对象不可达，可以被判定为可回收对象。

可以作为GC Roots的对象包括：

• 虚拟机栈中引用的对象，也就是正在执行的方法里的局部变量
• 方法区中类的静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI引用的对象
• JVM内部的引用，如基本数据类型对应的Class对象、常驻的异常对象、系统类加载器等
• 被同步锁（synchronized）持有的对象

这一段看起来偏理论，但排查内存泄漏的时候非常有用。你把堆转储文件导出来后，用MAT或者JProfiler看对象到GC Roots的引用路径，立刻就能定位到底是谁"钉住"了这些对象，让它们无法被回收。这个过程后面讲OOM排查时还会回到这里。

3.3 四种引用类型：强、软、弱、虚

在JDK 1.2之后，Java把引用分成了四种，引用类型的强弱直接决定了对象的回收时机。

强引用是最普通的Object obj = new Object()这种写法，只要强引用还存在，垃圾收集器永远不会回收被引用的对象。这也是最常见的内存泄漏原因——一个对象还被强引用持有，但它已经用不到了。

软引用用来描述一些还有用但非必须的对象。在系统将要发生内存溢出异常之前，JVM会先把软引用关联的对象列入回收范围进行第二次回收，如果这次回收后内存还是不够，才会抛出OOM。软引用非常适合做缓存，比如图片缓存、网页缓存，可以在内存紧张时自动释放一部分缓存对象。

弱引用比软引用更弱，只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存是否充足，都会回收掉只被弱引用关联的对象。WeakHashMap就是利用弱引用实现的，它的典型应用场景是缓存数据，但要注意弱引用被回收后，WeakHashMap的Entry里value还残留着强引用的话，还是会造成内存泄漏。

虚引用最弱，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获取一个对象实例。它唯一的用途是在对象被收集器回收时收到一个系统通知，主要用来实现堆外内存的回收。

3.4 经典回收算法：标记-清除、复制、标记-整理

判定对象可回收之后，接下来就看怎么回收了。业界有三种经典的回收算法，它们各有优缺点，现代垃圾收集器都是它们的组合或变体。

标记-清除算法是最基础的算法，分为标记和清除两个阶段。先标记出所有需要回收的对象，标记完成后统一回收。它的缺点是效率不高，而且清除之后会产生大量不连续的内存碎片，空间碎片太多会导致以后分配大对象时没有足够连续内存而提前触发GC。

复制算法把内存按容量划分为大小相等的两块，每次只使用其中一块，当这一块的内存用完了，把还存活的对象复制到另一块上面，然后直接把已使用的那块内存整块清理掉。这样每次都是对半个区域进行内存回收，分配内存时也不用考虑碎片问题。缺点是可用内存变为原来的一半，空间浪费比较明显。当前商业虚拟机的新生代回收采用的就是复制算法，但并不是按1:1划分，而是把Eden和两个Survivor区按8:1:1的比例划分，每次把Eden和一块Survivor中存活的对象复制到另一块Survivor上，这样就只浪费10%的空间。当Survivor空间不够时，需要依赖老年代进行分配担保。

标记-整理算法适合老年代场景。标记阶段和标记-清除一样，但后续不是直接清理，而是让所有存活对象向一端移动，然后直接清理掉端边界以外的内存。这样做解决了碎片问题，但移动对象意味着要更新所有指向这些对象的引用，会有额外的开销。

4. 主流垃圾收集器：从Serial到ZGC的演进

算法是理论方案，垃圾收集器是理论落地的工程实现。各款收集器的区别本质上是在延迟（停顿时间）和吞吐量之间做取舍。

4.1 Serial与Parallel：最朴素的年代

Serial是最基础的单线程收集器，进行垃圾收集时必须暂停所有工作线程，也就是"Stop The World"。它的优点是简单高效，对于单核CPU或者客户端模式下的JVM来说，没有线程切换开销，反而更高效。

Parallel收集器也叫吞吐量优先收集器，它的设计目标是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。-XX:MaxGCPauseMillis控制最大垃圾收集停顿时间，-XX:GCTimeRatio直接设置吞吐量大小。实际使用中，Parallel是JDK 8默认的新生代收集器（Parallel Scavenge + Parallel Old），很多跑批任务的系统至今还在用它。

4.2 CMS：并发收集的先行者

CMS（Concurrent Mark Sweep）是一款以获取最短回收停顿时间为目标的收集器，基于标记-清除算法。它的运作过程分为初始标记、并发标记、重新标记、并发清除四个步骤，其中初始标记和重新标记仍然需要Stop The World，但耗时很短，耗时最长的并发标记和并发清除阶段都可以和用户线程一起工作。

CMS有两个比较让人头疼的问题。第一个是它无法处理浮动垃圾，可能会出现Concurrent Mode Failure，进而触发一次Full GC。解决办法是预留一部分空间给用户线程使用，-XX:CMSInitiatingOccupancyFraction可以设定老年代使用率达到多少时触发CMS GC，预留空间可以缓解这个问题。第二个问题是空间碎片，因为是标记-清除算法，长期运行会产生碎片，之后可以通过-XX:UseCMSCompactAtFullCollection在Full GC时进行碎片整理。JDK 9开始CMS被废弃，JDK 14正式移除，但大量老项目还在用它，你面试时候说自己在维护老项目时还在用CMS，是完全合理的。

4.3 G1：区域化分代的集大成者

G1收集器是JDK 9之后的默认收集器。它把整个堆划分成多个大小相等的Region，虽然还保留了新生代和老年代的概念，但新生代和老年代不再物理隔离，它们都是一部分Region的集合。G1通过追踪每个Region的回收价值和回收所需时间，维护一个优先列表，每次根据允许的收集时间优先回收价值最大的Region，这就是Garbage First这个名字的由来。

G1相比CMS，最大的改进是通过基于Region的内存布局和局部回收的设计，做到了可预测的停顿时间模型。同时它使用的整体上是标记-整理算法，不会产生碎片。判断一个大对象能否存进某个Region时，G1有一个特殊的Humongous区，专门存放超过Region容量一半的大对象，连续多个Humongous Region存放更大的对象。

G1真正用好的关键在于参数调优。核心参数包括-XX:MaxGCPauseMillis（目标停顿时间，默认200ms）、-XX:G1NewSizePercent（新生代初始占比，默认5%）、-XX:G1MaxNewSizePercent（新生代最大占比，默认60%）、-XX:G1HeapRegionSize（Region大小，默认由JVM自动计算）。实际调优时，要根据应用的实时吞吐量和延迟要求来调整这些参数，不能盲目照抄网上的配置。

4.4 ZGC与Shenandoah：超低延迟的探索

ZGC的目标是把GC停顿时间控制在10毫秒以内，而且无论堆多大，停顿时间都不受影响。它基于Region内存布局，引入了染色指针和读屏障技术。染色指针把部分信息直接编码在指针上，这要求堆内存的起始地址必须对齐，而且不支持32位平台。ZGC的读屏障会在程序访问对象时参与进来，通过判断指针上的标记信息来决定是否需要处理，这个过程大多在用户态完成，因此大幅减少停顿。

Shenandoah是OpenJDK开源的一个低延迟收集器，也是第一款由非Oracle团队开发的收集器（来自RedHat），目标和ZGC类似。两者的实现思路存在一定差异，但对应用来说，选哪个更多看所在JDK版本和操作系统是否支持。

4.5 收集器选型建议

根据我的实际经验，如果系统对延迟没有极致要求、追求吞吐量，Parallel是比较稳妥的选择，尤其是跑批处理任务时。如果系统是Web服务、对响应时间有要求，G1是目前最均衡的默认选择。如果堆内存超大（几十GB甚至上百GB）、要求延迟极低，ZGC值得考虑，但需要容忍它更高的CPU占用和可能的兼容性问题。

不要轻易相信"XX收集器性能最强"的说法，不同场景、不同内存规模下最优收集器完全不同。最好用压测工具模拟真实流量，对比不同收集器下的GC日志和响应时间，用数据说话。

5. JVM内存参数调优：一份可以照抄的配置清单

参数调优是Java开发者绕不开的实践。这里整理一份常用配置清单，附上说明和推荐值，你可以直接参考着用，但所有数值都要结合自己系统的实际情况调整。

5.1 堆内存参数

基础的堆内存参数有三个：-Xms设置堆的初始大小，-Xmx设置堆的最大大小，-Xmn设置新生代大小。一般建议-Xms和-Xmx设为相同值，避免堆扩容带来的性能损耗。新生代大小通常设置为堆的1/3到1/4，具体看对象的生命周期分布。

-XX:MaxMetaspaceSize设置元空间最大值，如果系统动态生成大量类（比如热部署频繁、反射频繁），这个值要给足，否则可能会抛出Metaspace OOM。注意元空间用完和堆OOM不完全一样，排查时需要区分。

5.2 GC日志参数

JDK 8时代的GC日志参数和JDK 11以后有变化。JDK 8常用的是：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/path/to/gc.log

JDK 11以后统一了日志配置：

-Xlog:gc*:file=/path/to/gc.log:time,uptime,level,tags -Xlog:gc*:/path/to/gc.log:time,uptime,level,tags

GC日志是定位内存问题的第一手资料，里面可以看到每次GC的原因、耗时、回收前后各区域的使用情况。我不会想当然地说日志不重要，实际上排查任何一个线上内存问题，我做的第一步永远是打开GC日志，看Full GC的频率和触发原因，这一步能筛掉一半以上的问题。

5.3 OOM日志参数

-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=/path/to/dump.hprof这两个参数一定要加上。当发生OOM时，JVM会自动把当前堆内存快照导出到指定路径，这是后续分析的关键数据。很多同学线上环境没加这个参数，出了OOM之后只能靠猜，效率极低。

另外-XX:OnOutOfMemoryError参数可以指定一个脚本路径，OOM时自动执行脚本，比如自动重启服务或者发送告警，这在无人值守的线上环境里很实用。

5.4 一个参考配置示例

这里给出一个中等流量Web服务的参考配置（假设物理内存8GB）：

-Xms4g -Xmx4g -Xmn2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/jvm/dump.hprof -Xlog:gc*:/var/log/jvm/gc.log:time,uptime,level,tags

堆设4GB是给系统其他进程留了余量，新生代2GB让大部分短期对象在新生代就完成了回收。G1目标停顿100ms，对绝大多数Web服务来说体感很好。这个配置不是最优解，但是一套合理的起步配置，后续根据监控数据再做微调。

6. 内存泄漏与OOM：一次完整排查实战

到这一节，来点真正实战的东西。假设你在线上遇到一个OOM，日志显示java.lang.OutOfMemoryError: Java heap space，你该怎么一步步排查。

6.1 一个典型的内存泄漏示例

先看一个典型的泄漏场景：

public class LeakDemo { private static final List<byte[]> CACHE = new ArrayList<>(); public void addData() { // 模拟缓存数据不断积累 CACHE.add(new byte[1024 * 1024]); // 每次添加1MB } }

这段代码中，CACHE是静态变量，生命周期和JVM一样长。每次调用addData()都会向List中塞1MB数据，日积月累，堆内存就会被耗尽。这就是最常见的内存泄漏——对象被静态容器持有，永远不会被回收。

6.2 排查步骤：用MAT定位泄漏源头

第一步，确认OOM类型。Java heap space说明堆空间不足；Metaspace说明元空间不够；unable to create new native thread说明操作系统线程数到了上限，和堆无关。不同类型的OOM排查方向完全不同。

第二步，拿到堆转储文件。如果之前配置了HeapDumpOnOutOfMemoryError，OOM后自动生成的hprof文件就是排查的起点。如果没有，只能通过jmap -dump:format=b,file=/path/to/dump.hprof <pid>手动导出，但注意导出过程对线上性能有影响，谨慎操作。

第三步，用MAT（Eclipse Memory Analyzer）打开堆转储文件。MAT会自动分析出"Leak Suspects"，也就是最可能导致OOM的对象和它们的GC Roots引用链。点击查看"Dominator Tree"可以让大对象一目了然。我遇到过一个真实案例：一张报表查询每次执行都会往一个静态HashMap里塞查询参数，接口没人调用了但Map里的数据一直在增长，MAT一看Dominator Tree，一个HashMap占了几百MB，顺藤摸瓜就找到了代码里那个只增不减的静态Map。

第四步，分析完定位到具体的业务代码后，修复代码逻辑。修完重新压测，确认内存水位稳定，再发布上线。

6.3 除了堆OOM，这几种内存问题也很常见

栈溢出（StackOverflowError）通常是无限递归导致的，比较极端的场景是JSON序列化时对象的循环引用，A对象里有B，B对象里有A，序列化时无限递归，栈先爆了。

直接内存溢出表现为进程物理内存持续增长，但堆内存和GC日志都正常，最后进程被操作系统杀掉。常见原因是使用NIO或者Netty时，堆外内存分配后没及时释放。排查方法是用NMT（Native Memory Tracking）查看本地内存占用情况，启动参数加-XX:NativeMemoryTracking=detail，然后jcmd <pid> VM.native_memory查看明细。

线程数过多导致的OOM，报错是unable to create new native thread，这通常不是内存不足，而是操作系统限制的线程数被打满了。排查思路是查看ulimit -u（用户最大进程数）、/proc/sys/kernel/threads-max等系统参数，同时检查代码里是否有线程创建后没有正确停掉的情况。

6.4 避免内存泄漏的几个编程习惯

第一，警惕静态集合。静态容器配合add操作的场景，一定要考虑对象生命周期，明确什么时候remove。第二，注意IO流、数据库连接、网络连接等资源的关闭，推荐用Java 7之后的try-with-resources语法，它会自动调用close。第三，事件监听器和回调函数里如果被注册的对象比监听器活得久，一定要提供反注册的方法。第四，善用WeakReference、WeakHashMap，缓存场景下尤其适用。

7. 面试高频题速查：这些坑你都踩过吗

搜一下"Java面试"相关的热词，排在前面的基本都绕不开内存这一块。这里整理几个高频题，顺带把我踩过的坑也写进去，供你自查。

• 问题一：Java对象创建的过程是什么？面试官想听到的是从类加载检查、分配内存、初始化零值、设置对象头到执行init方法的完整链路，而不是一句"new出来的"。答的时候能带上指针碰撞、空闲列表、TLAB这些关键字，基本就过关了。
• 问题二：什么时候触发Full GC？老年代空间不足是最常见的答案，但完整的回答还包括元空间不足、System.gc()、CMS的Concurrent Mode Failure、堆外内存回收请求等。能说出-XX:CMSInitiatingOccupancyFraction参数和它解决的问题，面试官会认为你确实调过参。
• 问题三：如何排查线上OOM？这个一定要按步骤答：先看GC日志和OOM错误类型，然后通过HeapDumpOnOutOfMemoryError拿到堆转储，用MAT分析泄漏嫌疑，最后定位到GC Roots引用链上的业务代码。能顺带说出"不要在生产环境手动jmap导堆"这个经验，非常有加分效果。
• 问题四：强引用、软引用、弱引用、虚引用的区别？除了说清楚回收时机，如果聊到软引用适用缓存、弱引用适用WeakHashMap，再进一步说到虚引用用于堆外内存回收的通知机制，这题就答透了。
• 问题五：G1和CMS有什么区别？可以从内存布局（Region vs 物理分代）、停顿模型（可预测 vs 不可预测）、碎片问题（标记-整理 vs 标记-清除）、适用场景（大堆 vs 中小堆）四个维度回答。

8. 常见问题与避坑指南：最后给你一张速查表

把日常工作中经常遇到的情况整理成一组对照，直接照用就好：

再补充两个容易被忽视的坑。第一个，不要在代码里使用System.gc()，尤其是老项目，很多中间件监听了这个调用会触发Full GC，线上性能会莫名其妙出现波动。第二个，测试环境一定要模拟生产环境的JVM参数，很多问题只在特定堆大小下才会暴露，比如小堆下G1表现良好，大堆下就会频繁并发标记失败。

我自己的经验是，处理内存问题最忌讳"加内存"这个万能解法。加内存只是把问题往后推迟了，泄漏的代码不修复，堆再大也有一天会爆。正确做法是把OOM当作一次事故复盘的机会：先通过GC日志定位触发点，再通过堆转储找到泄漏源，修完代码后还要持续观察内存水位曲线，确认问题真正解决。

这篇文章写到这里，涵盖了Java内存区域划分、对象分配与晋升机制、垃圾回收的判定和算法、主流收集器选型、参数调优配置，以及OOM排查的完整路径。你在实际操作中如果遇到JVM内存相关的问题，把这些内容当作一份checklist来对照排查，会比直接搜报错信息高效得多。最后说一句，JVM参数和垃圾回收器的选择没有银弹，每一条配置决定都意味着某些场景的取舍，真正理解原理、学会看日志和数据，才是排查问题的底气。