JVM垃圾收集器完全指南：从内存模型到G1/ZGC实战调优

1. 从一次线上事故说起：我为什么决定把垃圾收集器彻底搞懂

做Java开发这些年，有个话题永远绕不开：Jvm垃圾收集器。尤其是在一次线上事故之后，我对它的态度从“能用就行”彻底转变成了“必须搞懂原理再动手调优”。

当时的情况是这样的：一个核心订单服务，堆内存给了8G，用的是JDK 8默认的Parallel Scavenge加Parallel Old组合，平时跑得好好的。结果双十一大促流量一上来，接口RT从50ms直接飙到5秒，紧接着频繁Full GC，每次停顿3秒以上，用户体验可想而知。当时团队几个人围着监控面板干瞪眼，jstat打出来的数据显示老年代疯狂增长，但业务代码肉眼查了几遍也没发现明显的大对象分配。

后来定位到问题并不复杂，就是某个查询接口在条件为空时会全表扫描，一次性把近百万条记录加载进内存做处理，老年代瞬间被打满。但让我真正后怕的是，当时整个团队对垃圾收集器可以说是一知半解，连G1和CMS的核心区别都说不清楚，更别提什么Region、RSet、SATB这些概念了。

从那次之后，我花了很长时间系统整理了JVM垃圾收集器的知识体系，从内存模型到对象存活判定，从串行收集器到ZGC，每一步都对照源码、参数和实践案例验证过。这篇文章就是整个知识体系的沉淀，目标读者是那些已经写过一段时间Java、对JVM有基本概念但还没系统梳理过垃圾收集器的同学，以及准备面试需要把这块吃透的开发者。

这篇文章能帮你解决什么问题？说直白点：第一，看懂GC日志，遇到线上卡顿不再抓瞎；第二，知道该选哪个收集器、怎么设置参数，而不是照抄网上的配置模板；第三，理解为什么G1会成为JDK 9之后的默认选择，以及ZGC到底牛在哪。

文章会有点长，但我尽量用讲人话的方式把每个概念拆开揉碎，结合真实的参数配置和排查案例来讲，保证你看完能直接在工作中用上。

2. 前置基础：搞懂收集器之前，必须先搞懂这三大块

2.1 Jvm内存模型：垃圾到底存在哪

要聊垃圾收集器，就得先知道垃圾在哪。这就好比你要请保洁阿姨打扫房间，总得先告诉人家卧室在哪、厨房在哪、卫生间在哪吧。JVM的内存模型，就是垃圾收集器的“户型图”。

直接看堆内存的划分，这在面试里也是高频考点：

• 新生代（Young Generation）：又细分为Eden区和两个Survivor区（From和To）。大部分对象刚创建时都在Eden区分配。为什么Survivor要两个？因为复制回收算法需要一个空闲区域作为目标地，两个Survivor轮换使用，每次回收后存活对象从一块Survivor复制到另一块，空的留作下次使用。

• 老年代（Old Generation）：经过多轮Minor GC后仍然存活的对象，或者大对象直接分配到这里。老年代的对象特点是生命周期长，垃圾回收频率低但单次代价高。

• 元空间（Metaspace）：JDK 8之后替代了永久代，存的是类元数据。它不在Java堆中，使用本地内存，默认情况下上限是物理内存大小，所以元空间的溢出往往是因为加载类太多，需要留意-XX:MaxMetaspaceSize参数。

这里顺便说一个热词里提到的关系：Jre和Jvm之间的关系，以及Jdk和Jvm、Jre的区别。简单说，JDK是Java开发工具包，包含JRE并额外提供编译器（javac）、调试器等开发工具；JRE是Java运行环境，包含JVM和核心类库；JVM是JRE最核心的部分，负责把字节码解释或编译成机器码执行。你在本地用JDK编译出的.class文件，部署到只有JRE的服务器上也能运行，但无法再编译源码。垃圾收集器就运行在JVM进程内部，负责管理Java堆。

理解了内存布局之后，垃圾收集器的工作范围就很清楚了：它管理的主要是堆内存，也就是新生代和老年代这两块。

2.2 对象生死判定：可达性分析是怎么回事

垃圾收集器拿到一堆对象，怎么判断哪些是垃圾？主流做法是可达性分析（GC Roots Tracing）。

基本思路：从一组称为“GC Roots”的根对象出发，沿着引用链遍历，能到达的对象就算“活的”，到不了的就判定为可回收。这个思路其实和很多图遍历算法一样，但难点在于“哪些对象算Root”。

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

• 虚拟机栈中引用的对象：也就是当前线程正在执行的局部变量表里的引用，比如方法里的局部变量、参数。
• 静态变量引用的对象：方法区中类的静态属性，比如说private static Config config = new Config()其中的config。
• 常量池引用的对象：比如字符串常量池里引用的String对象。
• JNI引用的对象：Native方法引用的Java对象。
• 同步锁持有的对象：被synchronized锁住的对象，在锁释放前肯定不能回收。
• JVM内部的引用：比如基本类型对应的Class对象、常驻的异常对象（如NPE的类）、系统类加载器加载的类等。

和可达性分析配套的是四种引用类型，这也是jvm面试题里常考的：

有个常被忽视的细节：SoftReference对象本身在内存不足时会被回收，但它的回收时机和堆大小、上次GC后的空闲内存比例都有关系，不能假设软引用一定会在OOM之前被清干净。我的建议是，正常情况下优先用合理的缓存策略（比如Caffeine）而不是软引用兜底，软引用更适合做“锦上添花”的优化，而不是“雪中送炭”的保命手段。

另外补充一个基础但重要的概念：finalize()方法。它确实能在对象被回收前做最后处理，但JVM不保证finalize会被及时执行，甚至可能根本不执行。在JDK 9以后这个机制已经被标记为废弃。真实的项目中永远不要依赖finalize来释放资源，这正是几乎所有Java规范都强调的。

2.3 分代收集理论：为什么要把堆拆成几块

有了可达性分析和引用类型这两个概念作为基础，接下来要理解的是垃圾收集的整体策略：分代收集。

分代理论的依据来自对大量程序的实际观察：

• 弱分代假说：绝大多数对象“朝生夕灭”，活不过几轮GC。
• 强分代假说：熬过越多次GC的对象，越不可能被回收，所以倾向于把它放到老年代，减少频繁扫描的成本。

听起来平平无奇，但不这么做会有问题。如果不分代，每次GC都要扫描整个堆的所有对象，然后标记存活对象、回收死亡对象，堆一大就扛不住，停顿时间会非常长。分代之后，Minor GC只需要处理新生代这一小块区域，因为大部分对象都死了，所以复制算法非常高效；老年代的对象很少被回收，可以降低扫描频率，为它配备更复杂的标记-整理或并发收集算法。

这里插一个生活化类比：分代收集就像是垃圾分类。厨房垃圾（新生代对象）几乎每天都要扔，所以小区安排了每天早上定时清理；而旧家具、废家电（老年代对象）可能好几年才处理一次，单独预约回收就行。如果每天把全小区的垃圾都翻一遍，效率肯定低得吓人。垃圾收集器也是同样的道理。

有了分代理论，再来理解各种收集器的设计，思路就顺了：每个收集器本质上都是在权衡“吞吐量”和“停顿时间”这两个指标。所谓吞吐量，就是CPU用于运行用户代码的时间占总时间的比例；所谓停顿时间，就是垃圾收集导致的Stop The World（STW）时间。两个指标往往是矛盾的，想要更短的停顿，就要付出更多CPU和内存开销，这也是后面所有收集器设计博弈的根源。

3. 七大垃圾收集器全景图：从Serial到ZGC

3.1 经典收集器逐个拆解：谁适合什么场景

顺着时间线来看主流收集器的演进，从早期的Serial到后来的G1、ZGC，每一代都是在解决上一代的核心痛点。我用一个表格来帮你快速建立全局认知，然后逐个展开。

Serial收集器：单线程、STW，虽然听起来很古老，但在客户端模式和嵌入式场景下依然有用。单核CPU下，多线程反而需要线程切换开销，Serial的简单反而成了优势。

Parallel Scavenge/Parallel Old：和ParNew的区别在于它关注的点是吞吐量可控，-XX:MaxGCPauseMillis和-XX:GCTimeRatio这两个参数就是为了调节吞吐量和停顿时间的。如果你跑的是离线计算、批处理任务，不希望GC占用过多CPU时间，Parallel是很合适的选择。JDK 8的默认组合就是Parallel Scavenge + Parallel Old。

ParNew + CMS：在很多老项目中非常常见，特别是互联网公司早期。ParNew负责新生代，CMS负责老年代。CMS的全称是Concurrent Mark Sweep，它的最大卖点是并发收集，也就是说老年代的标记和清理阶段不需要完全STW，可以和用户线程并发执行，这样停顿时间大幅缩短。但CMS有两个致命缺点，后面我单独用一节来讲。

G1收集器：JDK 9改为默认，JDK 11之后在大堆场景下表现出色。它不再严格区分新生代和老年代的物理连续内存，而是把整个堆划分为许多固定大小的Region，每个Region可以动态扮演Eden、Survivor或者Old的角色。G1的最核心能力是可预测停顿模型：你可以设置-XX:MaxGCPauseMillis=200，它能尽量保证每次GC停顿不超过200ms，这是前面几个收集器都做不到的。

ZGC：基于Region，引入了染色指针和读屏障，你可以把GC停顿控制在几毫秒甚至亚毫秒级别，而且停顿时间不随堆大小增长。ZGC在JDK 15之后转正，适合堆内存几十GB甚至上百GB的场景。当然代价是CPU使用率更高，如果机器核数不够，反而不如G1划算。

3.2 CMS为什么被淘汰：说透它的四个致命细节

CMS在很多Java开发者心中地位很高，一度是低延迟场景的事实标准。但它在JDK 9被标记为废弃，JDK 14移除了，面试官也喜欢问这个问题。我来把它淘汰的原因讲透。

第一个细节：CMS采用标记-清除算法，会产生内存碎片。标记清除算法只负责把死亡对象的内存标记出来然后释放，但不会整理存活对象，所以时间一长，老年代会出现大量不连续的空闲碎片。碎片多了之后，当一个大对象需要连续内存时，即使老年代总空闲空间足够，也找不到合适的连续区域，只能提前触发Full GC甚至抛出Concurrent Mode Failure。相比之下，标记-整理算法会移动存活对象、压缩内存，不会产生碎片。

第二个细节：CMS的并发阶段会和用户线程争抢CPU资源。CMS在并发标记和并发清理阶段不是完全STW的，但这意味着它要和业务线程同时运行。如果机器核数不多，CMS会明显拉高CPU占用，反过来影响应用的整体吞吐量。

第三个细节：浮动垃圾（Floating Garbage）问题。并发收集过程中，用户线程还在不断产生新的垃圾，这些垃圾只能留到下一次GC再处理。所以CMS在老年代的使用率还没到100%时就要提前触发GC，通常预留一部分空间，默认阈值是92%左右（-XX:CMSInitiatingOccupancyFraction可调）。预留的空间不够时，就可能出现Concurrent Mode Failure，然后退化成Serial Old做Full GC，停顿时间直接爆炸。

第四个细节：无法处理"并发失败"时的降级路径。一旦并发模式失败，CMS会退化为Serial Old，Serial Old是单线程的，停顿时间可能长达几十秒。这对在线业务来说几乎是不可接受的。

简单总结：CMS用并发换来了低停顿，但代价是碎片化、CPU争抢、浮动垃圾和退化风险，这些问题在堆上到10G以上时会被明显放大。G1正是在这些层面做了结构性改进，这就是为什么后来者居上。

3.3 G1凭什么成为默认：Region模型和可预测停顿

G1（Garbage First）从名字就能看出来思路：优先回收垃圾最多的Region。它并没有全盘推翻分代理论，而是把分代的思想用Region来重新诠释。

核心模型：Region

G1把整个堆划分为多个大小相等的Region，默认最多2048个，每个Region的大小通过堆大小除以2048计算，最小1MB，最大32MB。Eden、Survivor、Old这些角色不再有固定物理区域，而是由Region动态分配。比如Eden区占用的是一批Region，GC之后这批Region被清理，重新变成空闲Region供后续分配使用。

Region模型带来一个巨大的好处：每次GC不必扫描全堆。G1维护了一个优先级列表，每次回收时优先处理回收价值最高的Region集合，所谓回收价值，就是“回收掉这块区域能释放多少空间、耗时多少”。这种思路叫“回收价值优先”，G1名字里的Garbage First就是这么来的。

卡表与RSet（Remembered Set）

分代收集有一个经典难题：跨代引用。新生代的对象可能被老年代的对象引用，那么做Minor GC扫描新生代时，怎么知道这个对象被老年代引用着、不能回收？最粗暴的做法是扫描整个老年代，但代价太高。

G1的解法是为每个Region维护一个RSet，记录哪些Region中的对象引用了当前Region中的对象。这样每次GC只需要检查RSet，就能知道跨Region引用关系，不必全堆扫描。RSet的实现依赖卡表（Card Table），JVM把堆内存划分为512字节的卡页，卡表中每个字节对应一个卡页，记录了该卡页是否存在跨代引用。当发生引用写入时，通过写屏障把对应的卡页标记为“脏卡”（Dirty Card）。

这个机制和垃圾收集器之外的JIT编译也有关系，因为JIT会产生大量快速分配路径的代码，写屏障插入频率很高，所以现代JVM对写屏障做了很多优化，比如使用Dirty Card Queue异步处理，减少对业务线程的影响。

可预测停顿的实现

G1的-XX:MaxGCPauseMillis默认200ms，它的停顿预测模型基于历史数据：每次GC都会记录各阶段的耗时、Region回收速率，然后根据统计模型预测未来停顿时间。在年轻代GC中，它会根据停顿目标动态调整Eden Region的数量，如果你设置的最大停顿时间变短了，G1会减少Eden区的大小，让每次GC处理的对象更少，从而缩短停顿。这是一种以吞吐量换延迟的做法，所以不要为了追求极低停顿把MaxGCPauseMillis设得太小，否则GC会越来越频繁，吞吐量反而大幅下降。

G1的全局并发标记

G1的Full GC是串行的，这是它最需要规避的情况。为了避免Full GC，G1在正常运行时也会执行并发标记，标记老年代存活对象，计算每个Region的回收价值。这个过程中使用了SATB（Snapshot At The Beginning）算法，也就是在并发标记开始时给堆拍一张快照，所有并发标记期间发生的变化都基于这张快照来处理，这样可以避免传统CMS重新标记阶段的大幅STW。如果G1仍然发生Full GC，多半是因为堆本身不够用、大对象分配过多或者因为没有合理的GC调优参数，后面我会专门讲怎么做。

4. 实战：从参数到日志，把G1用明白

4.1 一组合理的生产环境JVM参数示例

工具选型这块，我直接给出在生产环境验证过的一段配置，然后逐行拆解。以JDK 11、堆内存8G为例：

bash复制-Xms8g -Xmx8g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=4
-XX:MaxMetaspaceSize=1g
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/oom_dump.hprof
-Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags:filecount=10,filesize=50m

逐个说：

• -Xms8g -Xmx8g：初始堆和最大堆一致，避免运行期频繁扩容和缩容。扩容不只是分配内存，还涉及堆内数据结构重建，是有代价的。
• -XX:+UseG1GC：显式指定G1。
• -XX:MaxGCPauseMillis=200：期望最大停顿200ms。记住这是“软目标”，不是硬性约束，大多数情况下可以达到，但堆严重不足时会失效。
• -XX:ParallelGCThreads=8：并行GC使用的线程数。这个值默认会根据CPU核数计算，通常建议不超过物理核数，太多反而压低业务线程的CPU。
• -XX:ConcGCThreads=4：并发标记的线程数。默认值约为ParallelGCThreads的1/4。如果老年代对象很多比较大，可以适当调大，但注意它要占用CPU，不能无限叠加。
• -XX:MaxMetaspaceSize=1g：限制元空间大小，防止类加载过多导致元空间无限膨胀。
• -XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath：OOM时自动导出堆快照，这个参数建议所有Java应用都加上，后面排查OOM全靠它了。
• -Xlog:gc*:file=/data/logs/gc.log:...：JDK 9+统一使用-Xlog语法输出GC日志，包括GC原因、堆变化、停顿时间等。JDK 8用的还是-XX:+PrintGCDetails -XX:+PrintGCDateStamps配合-Xloggc，如果你还在用JDK 8，那把参数换成对应的旧写法即可。

另外热词里提到的-XX:CompileThreshold，默认值10000，意思是方法被调用或循环执行超过10000次时触发C2编译。它和GC有关系吗？间接有关：编译后的机器码执行效率更高，能减少对象分配压力，该参数过高可能让热点代码长时间停留在解释执行阶段，导致分配对象更多、GC更频繁；太低又可能让JIT过度编译，启动时CPU飙升。除非你有非常具体的性能压测数据支撑，否则不要轻易调这个值。

4.2 如何读懂一份GC日志：G1日志实例逐行分析

下面给一段G1的日志摘录（字段含义做了简化保留），我们一步步读：

code复制[71.307s][info][gc,start] GC(3) Pause Young (Normal) (G1 Evacuation Pause)
[71.307s][info][gc,task] GC(3) Using 8 workers of 8 for evacuation
[71.310s][info][gc,phases] GC(3)   Pre Evacuate Collection Set: 0.8ms
[71.310s][info][gc,phases] GC(3)   Evacuate Collection Set: 2.4ms
[71.310s][info][gc,phases] GC(3)   Post Evacuate Collection Set: 0.5ms
[71.310s][info][gc,heap] GC(3) Eden regions: 16->0 (1.0M->0.0M)
[71.310s][info][gc,heap] GC(3) Survivor regions: 4->4 (0.2M->0.2M)
[71.310s][info][gc,heap] GC(3) Old regions: 12->15 (6.0M->7.5M)
[71.310s][info][gc,metaspace] GC(3) Metaspace: 60.5M->60.5M(1024.0M)
[71.310s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 16M->12M(8G) 3.7ms

逐行解读：

• 71.307s表示JVM启动后71.307秒发生的GC，这是定位线上问题时间线的重要锚点。
• Pause Young (Normal)，这是一次正常的年轻代GC，原因是G1 Evacuation Pause，也就是把Eden区存活对象复制到Survivor或老年代。
• Using 8 workers of 8，这次GC用了8个并行线程。
• 三个phases展示的是具体的三个阶段：Pre Evacuate、Evacuate、Post Evacuate，可以简单理解为准备、复制迁移、收尾。耗时加总约3.7ms，这就是这次GC的STW总时长。
• 堆变化：Eden从16个Region归零，Survivor维持在4个Region，Old从12个Region增长到15个。这说明有3个Region的对象年龄增长进入了老年代。
• 最底下那行的16M->12M(8G)表示本次GC后堆总用量从16M降到12M，总堆大小8G。这个日志最大的作用，是让你判断有没有异常的大对象分配、老年代是否增长过快、GC频率是否正常。

4.3 常见的G1参数调优策略

G1调优有一个重要的原则：先能用，再能跑，最后才优化。不要一上来就调一堆参数，先把默认配置跑起来，用监控工具观察一段时间，看GC频率、停顿时间、堆使用趋势，有了数据再动手。

常见的调优路径：

• 如果GC频率高，但每次停顿短：说明堆太小或对象分配速率过高。优先考虑增大堆内存，堆内存不能满足时，再去找代码里有没有大量无用对象的分配。
• 如果每次停顿超过预期：检查MaxGCPauseMillis是否设得太小，导致G1频繁触发GC；或者堆特别大且每次需要复制大量Region。一个常见优化是加大-XX:G1HeapRegionSize，减少Region数量，降低RSet维护开销，但要注意Region太大会导致Eden区粒度过粗。
• 如果老年代增长过快：排查是不是存在大对象直接进入老年代，大对象在G1中占据多个连续Region，会显著影响回收效率。可以通过-XX:G1HeapRegionSize调整Region大小，如果对象很大，可能要考虑用-XX:G1MaxNewSizePercent控制新生代上限，或者从代码层面拆分大对象。

还有一个容易被忽略的经验：不要在生产环境开-XX:+PrintGCDetails这类日志时，忘记打开日志轮转。GC日志如果不做轮转，单文件会越来越大，撑爆磁盘后应用可能直接挂掉。上面配置文件里已经加了filecount和filesize两个参数，GC日志最多保留10个文件，每个最大50M，这就够用了。

5. 面试高频点：内存模型、G1回收过程与参数细节

5.1 一张图式记忆：从内存模型到GC Roots，再到收集流程

面试官问Jvm垃圾收集器，其实问的是一个完整链路：内存模型 → 对象怎么创建 → 对象怎么判断存活 → 不同代怎么回收 → 用哪个收集器 → 参数怎么配 → 出问题怎么查。

这套链路用文字可以串成一条逻辑：

1. 对象先分配到Eden区。Eden满了就触发Minor GC，使用复制算法，把存活对象复制到一块空的Survivor区。
2. 每经历一次Minor GC存活下来的对象年龄+1，年龄达到阈值（默认15）后晋升到老年代。
3. 大对象直接进入老年代，避免在新生代反复复制。
4. 老年代空间不足时触发Major GC/Full GC，根据收集器不同，使用标记-清除或标记-整理算法。
5. 所有回收的前提是可达性分析，而可达性分析的起点就是GC Roots。

面试还常考一个问题：什么是STW（Stop The World）？ 无论哪种收集器，至少在某一个或多个阶段会暂停所有用户线程，这就是STW。暂停的主要目的是保证在垃圾收集过程中对象引用关系不发生变化。G1和CMS用并发标记来减少STW，但复制阶段仍然需要STW。你只要能把这些说清楚，面试官就会觉得你是有实操经验的。

5.2 G1的完整回收过程拆解

G1的回收过程是一个循环往复的大流程，拆开来看主要有四步：

第一步，年轻代GC（Young GC）。Eden区满时触发，把Eden区的存活对象复制到Survivor区，或年龄够了就晋升到Old区。整个过程是STW的，但G1用了多线程并行，所以停顿可控。

第二步，并发标记（Concurrent Marking）。不是每次Young GC后都会触发，而是在堆空间占用率达到-XX:InitiatingHeapOccupancyPercent（默认45%）时启动。整个标记过程分为初始标记（STW）、并发标记（与业务线程并行）、最终标记（STW）、清理（STW，但停顿很短）几个子阶段。

第三步，混合回收（Mixed GC）。并发标记完成后，G1知道哪些老年代Region回收价值高，于是不只回收年轻代，还会回收一部分老年代Region，这就是混合回收。Mixed GC通常会连续执行多次，直到垃圾占比降到安全线以下。

第四步，Full GC。G1的Full GC其实是串行回收，过程和Parallel Old类似，但STW时间很长。Full GC一旦发生，说明前面的机制都没能兜住，要么堆不够，要么分配速率过高，要么回收跟不上分配。这是线上最需要警惕的情况。

5.3 关于jvm调优参数，面试官真正想听什么

面试聊到jvm参数，最忌讳背参数列表。面试官更在意的是你能根据场景选参数、说出为什么。

例如他问G1中-XX:MaxGCPauseMillis怎么设置，你上来就说200，这就很单薄。更好的回答是：先说明这是一个软目标，然后讲清它的实现逻辑——G1会根据历史GC数据动态调整Eden区大小来匹配目标停顿时间，设得太小会导致Eden更小、GC更频繁，吞吐量下降；然后结合业务场景说，如果接口对RT敏感，可以把目标设为100-200ms，后台计算任务反而可以设大些，比如400ms以上，让GC次数少一点。

再比如他问-Xms和-Xmx为什么不一致，你可以回答：不一致时JVM在运行期需要动态扩容和缩容，这个操作是STW的，虽然时间一般不长，但在大促这类流量峰值场景会被放大。所以线上核心应用都应该设置成一致。

再把热词里的两个问题串进来：

• jvm参数 -xx:compilethreshold：这个参数控制C2编译的触发阈值，默认是10000。它的作用是让JIT在方法足够“热”之后才做深度编译，避免什么方法都编译、浪费编译线程和时间。如果你发现某个热点方法长时间以解释模式运行，可以适当调低阈值；但默认值已经经过大量调整和验证，没有明确性能问题就不要动它。
• jre和jvm之间的关系：JVM是JRE的一部分，JRE还包括运行Java程序所需的类库；JDK则是在JRE的基础上添加了开发工具。它们的关系决定了你在开发环境写代码、在服务器跑程序时，安装的东西不一样。服务器只需要JRE（或精简后的JDK），但如果你要在服务器上做远程调试或运行一些诊断工具，最好装JDK。

6. 踩坑记录与排查方法：Java进程异常退出怎么办

6.1 容器中Java进程莫名重启：GC日志去哪儿找

这是一个非常实际的问题，也是热词里出现过的场景：docker容器部署的java程序，异常重启，jvm日志在哪儿。

很多Java进程在容器里跑着跑着突然退出，看业务日志根本没记录异常，这时大概率是进程被操作系统杀掉了，而不是Java内部报错。经典的元凶有两个：容器内存超限被OOM Killer杀掉，或者健康检查失败被编排系统重启。

排查步骤，按顺序来：

第一步，确认进程退出的信号。在宿主机上执行dmesg | tail -n 100，如果有Out of memory: Kill process相关日志，基本可以确认为OOM Killer。容器环境下，把dmesg的输出与容器主进程PID对一下就能定位。

第二步，如果确认是容器内存超限，要注意JVM看到的内存和容器限制的内存可能不一致。老版本JDK默认只认宿主机内存，容易把堆设得比容器限额还大，导致OOM。JDK 8u131+和JDK 9+开始支持-XX:+UseContainerSupport（JDK 8u191后默认开启），但更稳妥的做法是在启动参数里显式设置-Xmx，并确保它不超过容器内存限额的70%-80%。

第三步，还要注意JVM除了堆内存，还有一些“堆外内存”：直接内存（Direct Memory）、线程栈（线程数乘以栈大小）、元空间、JIT编译的代码缓存（Code Cache）等。G1和ZGC本身也需要额外的内存用于RSet等数据结构。所以容器内存限制500M，-Xmx却设400M，依然可能因为堆外内存超限被杀掉。安全的经验值是：容器内存至少是-Xmx的1.2到1.3倍。

第四步，关于GC日志在哪找：如果你在启动脚本里配置了-Xlog:gc*:file=/data/logs/gc.log，GC日志就在容器内的/data/logs/gc.log。但容器被杀了之后，日志在容器重启后可能就丢了，所以最好把GC日志的路径挂载到宿主机的数据卷上，比如用Pod的volume或Docker的bind mount。同理，OOM时的Heap Dump也要导出到持久化目录，不然重启一次什么都没留下。

6.2 一次真实的大对象导致的Full GC排查

再分享一次我处理过的线上案例，帮助你建立排查思路。

现象：应用每天下午固定时间RT变长，GC日志显示老年代GC频繁，且偶发Full GC。

我先用jstat观察堆变化：

bash复制jstat -gcutil <pid> 1000

输出里看到Eden区使用率持续高位，Old区不断上升，Full GC次数在增长。然后用jmap导出堆快照，再用MAT分析。很快发现有个HashMap，里面有近百万条记录，占了几百MB，是被一个定时任务一次性加载进来的。这个定时任务每天下午跑一次，每次跑完HashMap引用没有及时释放，导致老年代被撑满。

这个问题的本质不是GC参数不对，而是代码产生了大量生命周期较长的对象。参数只能延缓，治本还得改代码。我把定时任务改成数据分批加载，处理完一批就提交一批、清理引用，然后把SQL优化成分页查询，内存峰值直接降了4倍，Full GC从此消失。

这个案例说明一个很重要的道理：GC调优90%的收益来自代码优化和内存分配模式的改善，纯参数调优能做的事情很有限。遇到GC问题，第一个动作一定是看GC日志、堆快照、对象分配情况，而不是急着调参数。

6.3 问题排查速查表和常用工具清单

工具方面，我日常用得最多的是这几个：

• jps：列出Java进程。
• jstat：实时观察GC统计信息、类加载情况，参数-gcutil最常用来观察堆使用百分比和GC次数。
• jmap：打印堆内存详情或导出堆快照。生产环境慎用jmap，因为导出大堆本身会有短暂停顿。尽量用jmap -dump:live减少垃圾对象。
• jstack：导出线程快照，排查死锁、线程阻塞、CPU飙高时很有用。
• MAT：分析堆快照，查看支配树、怀疑点等。也可以用Eclipse MAT的OQL查询对象，查到可疑对象后反查GC Roots路径。
• Arthas：阿里开源诊断工具，在线反编译、监控方法调用、查看类加载器等，很强大，强烈建议日常开发装一个。

7. 选型建议与个人经验总结

7.1 怎么给你的项目选垃圾收集器

这是我被问得最多的问题：到底用G1还是CMS？要不要上ZGC？

一个负责任的回答是：看场景，没有银弹。

• JDK 8且堆内存小于4G：用默认的Parallel Scavenge + Parallel Old就足够稳定，没必要为了追逐新技术换G1。这个组合吞吐量高、团队熟悉度高、排障经验多。
• JDK 8且堆内存4G-20G、延迟敏感：推荐G1。虽然CMS在JDK 8上也能跑，但维护成本、碎片化、Concurrent Mode Failure这些风险都要自己背。
• JDK 11及以上：默认就是G1，除非你有非常特殊的需求，否则不要改回CMS（JDK 14已经移除CMS，改了也没用）。
• 堆内存超大（几十G以上）且需要超低延迟：ZGC是更好的选择。它的停顿不随堆增大而线性增长，配合JDK 21的ZGC，吞吐量也比早期版本好了很多。
• 延迟不是第一优先级，吞吐量更重要：比如离线批处理、报表计算，Parallel组合可能比G1更合适，因为G1为了可预测停顿付出了额外的CPU开销。

个人还有个建议：不要只看收集器的名气和趋势，要看你们团队能Hold住哪种复杂度。G1的调优参数比CMS多很多，如果团队没有人真正懂Region和RSet，出了问题只会照着网上参数抄，那还不如用默认组合来得稳。

7.2 把GC调优当成持续迭代的过程

GC调优不是一次性的工作，它应该跟着应用的生命周期持续迭代。

我自己的实践节奏是：

1. 上线前：明确最核心的性能指标——最大STW时间、GC频率、吞吐量底线。根据这个选收集器和初始参数。
2. 上线初期：多开GC日志、加HeapDump、加监控。观察有没有明显异常，比如某个接口触发的对象分配特别多。
3. 运行期：每次大版本发布后，压测一轮，对比GC指标。如果发现GC模式变化，优先回到代码层面找原因。
4. 故障后：把每次故障的GC日志、堆快照、线程快照归档，并沉淀成文档，团队内共享。

这里特别想提到的经验是：调优不要一次性改多个参数。很多新手喜欢一次加五个参数然后跑一下看结果，结果出问题了根本不知道是谁引起的。正确做法是一次只改一个，观察一段时间，通过GC日志确认效果后再做下一步。改完参数后，必须回到业务指标（RT、TPS、错误率）去看效果，不要只看GC时间短了，如果业务吞吐量掉得很厉害，那就说明这组参数得不偿失。

7.3 从理解到实践：我的最后几点提醒

按照我个人的经验，刚开始接触Jvm垃圾收集器的人最容易犯的几个错误：

• 背了一堆参数但不知道默认值是什么。因为你不知道默认值，就无法判断当前运行的JVM处于什么状态。建议花时间过一遍java -XX:+PrintFlagsFinal -version输出的所有参数，至少把几十个高频参数的默认值记心里。
• 只关心堆内存，忽略堆外内存的影响。直接内存溢出时同样会抛OOM，但堆快照看起来可能很干净。排查时要结合操作系统层面的内存指标一起看。
• 把G1当成万能解。G1也不是万能的，它特别怕超大对象和极高的分配速率，这两种情况都很容易触发Full GC。
• 生产环境日志配置不全。没有GC日志、没有HeapDump、没有线程快照，出了故障只能靠猜。建议所有生产Java应用在第一天就把这些加上。

最后分享一个我早期踩过的坑：当时为了调低GC停顿，把-XX:MaxGCPauseMillis设成了50ms，结果G1疯狂触发GC，每次GC停顿虽然短，但频率翻了4倍，吞吐量直接腰斩。后来用压测数据对比才发现，200ms的目标对这个服务才是最优的。所以参数不是越小越好，一切要以业务指标为准。

垃圾收集器的世界还在持续演进，JDK后续版本里ZGC和新的分代实现也还在不断优化。但不管收集器怎么变，内存模型、可达性分析、垃圾回收算法、参数调优方法论这些底层的知识永远不会过时。把这些吃透了，无论将来面对什么样的新垃圾收集器，你都能很快上手。