01-04-B-垃圾回收面试与生产事故实战导读这是《垃圾回收机制详解》的配套 B 篇。GC 是 Java 面试深挖的终点站——从怎么判断对象死了一路追问到ZGC 为什么快答不上来就暴露深度。本篇把高频题按追问链一问一答连贯展开生产事故按场景 → 根因 → 预防 → 解决 → 一句话教训五段式复盘。原理细节标注见 A 篇 x.x 节。全文约 8900 字。 目录01-04-B-垃圾回收面试与生产事故实战一、高频面试题精讲连贯问答链链条①判死与引用四连问链条②算法与分代三连问链条③收集器五连问链条④调优三连问二、生产事故案例集五段式复盘事故一导出接口 8MB 字节数组G1 每 5 分钟 Full GCHumongous事故二老年代碎片化CMS 深夜连环 Full GC标记-清除的债事故三缓存用软引用OOM 前 GC 疯狂空转软引用的陷阱事故四System.gc() 被 RMI 定时触发每小时一次 2 秒停顿事故五Metaspace 触发 Full GC 风暴Groovy 脚本再立功元空间水位三、事故速查表四、面试答题万能框架五、与 A 篇的知识点映射一、高频面试题精讲连贯问答链链条①判死与引用四连问Q1怎么判断对象可以被回收为什么不用引用计数【30 秒电梯版】可达性分析从 GC Roots栈局部变量、静态变量、常量、JNI 引用、锁持有对象等七类出发遍历引用链不可达即死。引用计数被弃用因为①循环引用互相计数不归零 ②每次赋值维护计数有性能税。【深挖版】要点说明GC Roots 七类清单要能背A 篇 2.1——排查内存泄漏时 MAT 的 “Path to GC Roots” 就是反向走这条链—不可达 ≠ 立即死还有 finalize() 的缓刑机会只执行一次、不保证运行别用它做资源清理——try-with-resources 才是正解呼应《Java基础深水区详解》2.4加分点说出可达性分析需要在安全点停顿做初始标记——把判死与 STW 串起来。【追问链】GC Roots 里的静态变量让你想到什么事故→ Q2Q2四种引用类型及应用场景【30 秒电梯版】强永不回收普通引用、软内存不足才回收内存敏感缓存、弱下次 GC 就回收ThreadLocalMap 的 key、WeakHashMap、虚随时回收且 get 不到配合 ReferenceQueue 做清理通知——DirectByteBuffer 的 Cleaner。【深挖版】要点说明ThreadLocal 泄漏完整机理key 弱引用被 GC 变 nullvalue 是强引用还挂在线程的 ThreadLocalMap 上线程池线程不死 → value 永存 → 泄漏 数据串号。所以必须 remove《JVM内存模型与对象面试与生产事故实战》事故五软引用做缓存已被淘汰的原因回收时机不可控内存不足才收收之前可能先 OOM 边缘试探、无过期/容量语义——Caffeine 全面替代虚引用 ReferenceQueue 是对象死亡通知机制Cleaner 靠它在堆内对象死亡时释放堆外内存A 篇 2.1内存篇 2.7。【追问链】对象判死后怎么清理→ Q3Q3finalize() 和 try-with-resources 怎么选【30 秒电梯版】无脑 try-with-resources。finalize 三宗罪①执行时机不确定GC 才触发可能永远不触发②性能差有 finalizer 的对象要经过两轮 GC 才能回收③可能复活对象this 逃逸。JDK 9 已标记 DeprecatedJDK 18 标记 forRemoval。【深挖版】要点说明两轮 GC第一轮标记 入 F-QueueFinalizer 线程执行 finalize 后对象若被复活赋给静态变量则逃脱第二轮才真正回收——finalizer 线程是低优先级的堆积会拖慢回收CleanerJDK 9是 finalize 的替代品但定位是最后的安全网Netty 的 ByteBuf 泄漏警告就靠它资源管理依然首选显式 close。—Q4对象一定分配在堆上吗【30 秒电梯版】不一定。JIT 的逃逸分析对象不逃出方法 →标量替换拆成局部变量直接在栈帧分配出栈即消失零 GC 成本不逃出线程 → 锁消除。所以所有对象都在堆上这句话在现代 JVM 上是错的。【深挖版】要点说明严格说 HotSpot 没有真正的栈上分配对象是标量替换对象被拆散压根没创建完整对象——说出这个细节是强加分项—逃逸分析三优化栈上分配标量替换、锁消除方法内 StringBuffer 的 synchronized 直接删、锁粗化连续加解锁合并-XXDoEscapeAnalysis 默认开-XX:-DoEscapeAnalysis关闭后堆分配暴涨——可以自己实验验证。链条②算法与分代三连问Q5GC 算法有哪些为什么新生代用复制、老年代不用【30 秒电梯版】四算法标记-清除简单但碎片、标记-复制无碎片但费空间、标记-整理无碎片不费空间但慢、分代收集总纲。新生代 98% 对象朝生夕死 → 复制成本只与活对象成正比 → 极划算老年代存活率高 → 复制一半对象太贵且无担保空间 → 用清除或整理。【深挖版】要点说明新生代复制的改良不是 1:1 对半分浪费 50%而是 Eden:S0:S1 8:1:1——只浪费 10%S1 做分配担保A 篇 2.2碎片的实际危害标记-清除后总空间够但连续空间不够大对象分配失败 → 提前 Full GCCMS 的死穴之一与 MySQL 篇呼应页分裂/页合并是磁盘世界的碎片治理GC 整理是内存世界的同款问题。【追问链】Minor GC 和 Full GC 的区别与触发→ Q6Q6Minor GC / Major GC / Mixed GC / Full GC 的区别Full GC 什么时候触发【30 秒电梯版】Minor GC 收新生代Eden 满触发频繁但快Major GC 严格指只收老年代Mixed GC 是 G1 特有新生代 高价值老年代 RegionFull GC 整堆 元空间。触发五条件老年代不足、元空间不足、System.gc()、CMS 并发失败、空间分配担保失败。【深挖版】要点说明G1 服务出现 Full GC 必有异常Humongous 分配失败/晋升失败/元空间——正常运行的 G1 应该零 Full GC这是监控告警规则A 篇 4.2 观测与 4.5 验证本篇事故一—System.gc() 的坑默认触发 Full GCNIO/RMI 会帮你调用它——-XX:ExplicitGCInvokesConcurrent转为并发执行别用 DisableExplicitGC 一刀切会断掉 DirectByteBuffer 的 Cleaner 回收路径堆外泄漏内存篇事故三空间分配担保Minor GC 前检查老年代最大连续空间 历次晋升平均值不满足就先 Full GC 腾地方——老年代碎片化时这里最容易炸。【追问链】什么是 STW为什么必须停→ Q7Q7什么是 STW安全点是什么【30 秒电梯版】STW Stop The WorldGC 时暂停所有业务线程。必须停的原因标记过程中对象图在变业务线程改引用不停就标不准。安全点Safepoint 线程允许被暂停的特定位置方法调用/循环回跳/异常跳转GC 时所有线程要跑到最近的安全点才停。【深挖版】要点说明隐蔽停顿STW 总时长 等待所有线程进入安全点Time To Safepoint, TTSP GC 工作。大循环里没有安全点可数循环 counted loop如for(int i0; i10000000; i)会让 TTSP 飙升——GC 日志显示停顿 50ms业务却卡了 500ms元凶就是 TTSP排查-Xlog:safepointJDK 9看 TTSP解法-XX:UseCountedLoopSafepoints 或改循环写法ZGC 的突破本质把必须 STW 的活对象图修正用染色指针读屏障转嫁给业务线程顺手完成STW 只剩扫 Roots 的亚毫秒操作A 篇 2.4。链条③收集器五连问Q8说说 GC 收集器的演进【30 秒电梯版】一条主线停顿目标越来越激进Serial单线程全停→ Parallel多线程全停吞吐王→ CMS并发标记清除第一次边跑边收→ G1Region 化 可设停顿目标JDK 9 默认→ ZGC/Shenandoah亚毫秒停顿且不随堆增长→ JDK 21 分代 ZGC低停顿分代吞吐兼得。【深挖版】要点说明每代的思路跃迁Parallel 是既然要停就多叫人CMS 是能不一起干的活别停业务G1 是把堆切块每次只收性价比最高的ZGC 是让业务线程顺手把 GC 的活干了读屏障自愈版本事实CMS JDK 9 标记废弃、JDK 14 移除G1 JDK 7u4 引入、JDK 9 默认ZGC JDK 11 实验、15 转正、21 分代化A 篇第一章时间线。【追问链】CMS 为什么被淘汰→ Q9Q9CMS 的工作原理和三大缺陷【30 秒电梯版】四阶段初始标记STW 短→ 并发标记与业务并行→ 重新标记STW 修正变动→ 并发清除。三缺陷①标记-清除算法留碎片大对象分配失败退化为 Serial Old 长停顿 Full GC ②并发阶段占 CPU默认 (核数3)/4 线程③Concurrent Mode Failure并发清除时老年代被晋升填满 → 单线程 Full GC 灾难停顿。【深挖版】要点说明增量更新并发标记时业务把黑对象指向白对象漏标风险CMS 记录这类引用新增重新标记阶段重扫——写屏障记录新增与 G1 的 SATB 对照G1 记录被删除的引用按开始快照算存活重新标记更短但浮动垃圾略多A 篇 5.2 对比表答题升华CMS 证明了并发收集可行G1 用 Region复制解决了它的碎片死穴——技术演进是保留优点修复缺陷的接力。【追问链】G1 凭什么成为默认→ Q10Q10G1 的核心设计MaxGCPauseMillis 是不是越小越好【30 秒电梯版】三板斧①堆切成 ~2048 个等大 Region分代变逻辑概念 ②跟踪每个 Region 的回收价值空间/耗时优先收价值最高的Garbage First③可预测停顿模型按 MaxGCPauseMillis 目标决定每次收多少 Region。不是越小越好设 10ms 会导致每次只敢收极少 Region回收速度赶不上分配速度 → GC 更频繁甚至退化 Full GC。【深挖版】要点说明Humongous Region超过 Region 一半的大对象专用连续 Region——大对象多的服务调大 G1HeapRegionSize本篇事故一、A 篇第四章实战IHOPInitiatingHeapOccupancyPercent默认 45%堆占用达此水位启动并发标记——老年代增长快的服务调低给标记留时间退化路径Evacuation Failure复制活对象时没地方放→ Full GCJDK 10 并行化仍是长停顿信号。【追问链】ZGC 为什么能做到亚毫秒→ Q11Q11ZGC 为什么停顿不随堆大小增长【30 秒电梯版】两项技术染色指针把标记位/重映射位存进 64 位指针的高位看指针就知道对象状态读屏障业务线程读引用时顺手检查指向旧地址就当场修正self-healing。于是修正全堆引用这个 O(堆大小) 的活被摊派给业务线程顺手完成STW 只剩扫描 GC Roots与堆大小无关只与线程数/Roots 量相关——所以 16G 和 16T 停顿一样短。【深挖版】要点说明对比 G1G1 的引用修正remembered set 处理、重定位需要 STW 且随 Region 数增长ZGC 把它并发化了代价读屏障约 5%~10% 吞吐开销浮动垃圾多并发期间死的对象下轮才收→ 内存占用要留余量JDK 21 分代 ZGC加入弱分代假说红利年轻代高频小回收分配速率高的应用吞吐显著改善——当前大堆低延迟的最优解染色指针的前提Linux x86-64 的虚拟地址高位闲置——所以 ZGC 早期只支持 64 位 Linux。【追问链】实际项目怎么选→ Q12Q12你的项目用什么收集器为什么【30 秒电梯版】示例答题按真实情况改编常规业务服务JDK 17 G1堆 8GMaxGCPauseMillis200——停顿可控、运维成熟、团队熟悉。压测发现导出场景 Humongous 分配触发 Full GC 后业务改流式分页 G1HeapRegionSize 调到 16m 解决A 篇第四章实战。延迟敏感的新服务在试点 JDK 21 分代 ZGC。【深挖版】要点说明这题考的是决策过程不是背参数说清业务特征堆大小/延迟要求/分配速率→ 收集器 → 关键参数 → 观测验证的闭环反面教材式答题“网上抄了套参数”——面试官立刻追问参数含义露馅永远补一句先有 GC 日志观测再谈调优Q13。链条④调优三连问Q13GC 调优的一般步骤看哪些指标【30 秒电梯版】五步①开 GC 日志-Xlog:gc*②分析三指标——停顿 P99不是平均、GC 频率、回收效率回收后占用是否持续爬升③定位类型频率高Eden 小或分配速率高停顿长老年代大/碎片/Full GC爬升泄漏 ④对症下药业务修复优先于参数⑤压测验证。工具GCEasy/GCViewer 出报告。【深挖版】要点说明回收后占用持续爬升是泄漏的 GC 侧信号——与 heap dump 分析内存篇互相印证—调优目标要先问业务吞吐型批处理容忍长停顿要总吞吐延迟型API要 P99——目标不同参数相反Parallel vs ZGC90% 的GC 问题根因在代码大对象、大查询、无界缓存、频繁创建大集合——参数是止痛药代码是病根A 篇 6.2 第十条。【追问链】常见的 JVM 参数怎么配→ Q14Q14生产环境 JVM 参数怎么配【30 秒电梯版】基线模板8G 容器、G1、JDK 178G 容器 · G1 · JDK 17基线模板堆占 limit 约 70%-XX:InitialRAMPercentage70.0-XX:MaxRAMPercentage70.0或写死 -Xms6g -Xmx6g两者必相等收集器-XX:UseG1GC-XX:MaxGCPauseMillis200别设太激进否则新生代被压小GC 更频繁元空间-XX:MetaspaceSize256m-XX:MaxMetaspaceSize512m防启动期频繁 Full GC 防吃光物理内存堆外-XX:MaxDirectMemorySize1g超限抛 JVM 内 OOM有日志好过被 OS 静默击杀 137兜底-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/data/dump-Xlog:gc*:file/logs/gc.log:time,uptime:filecount5,filesize50m内存账堆 6g 元空间 512m 线程栈 直接内存 1g 杂项 ≈ 8g limit堆不是越大越好是给堆外留活路【深挖版】要点说明每个参数的为什么XmsXmx 防运行期扩缩容停顿MetaspaceSize 256m 防启动期频繁 Full GC默认 21m 太小MaxDirectMemorySize 防堆外静默吃满容器exit 137HeapDumpOnOOM 是留全尸的最后一道保险——全部呼应内存篇 3.1/3.2容器内存账堆 6g 元空间 512m 线程栈 直接内存 1g 杂项 ≈ 8g limit——堆不是越大越好是给堆外留活路大堆32G低延迟换-XX:UseZGC -XX:ZGenerationalJDK 21。【追问链】线上突然 GC 恶化怎么办→ Q15Q15线上服务 Full GC 突然频繁你的排查 SOP【30 秒电梯版】六步①GC 日志确认 Full GC 原因字段Humongous/晋升失败/元空间/System.gc②jmap -histo:live 看谁占堆或 dump 后 MAT③区分泄漏回收后占用爬升vs 大对象byte[] 巨型数组vs 元空间类加载数④对应处置泄漏找 GC Roots 引用链、大对象改流式、元空间查动态类生成 ⑤止血重启保命 摘流量 ⑥复盘沉淀监控告警。【深挖版】要点说明完整实战案例A 篇第四章导出接口 8MB byte[] → Humongous → Full GC三层治疗本篇事故一/二各演示一种分支先止血后查因的顺序意识dump 大堆会 STW 数秒——生产先摘流量再 dumpjmap -dump:live 会触发 Full GC慎用优先 jcmd GC.heap_dump 或自动 dump详细工具链jstat/jmap/jcmd/arthas/MAT留给 1.6《JVM 排查实战》篇。—二、生产事故案例集五段式复盘事故一导出接口 8MB 字节数组G1 每 5 分钟 Full GCHumongous事故场景订单查询服务 P99 从 80ms 恶化到 1.5s每隔几分钟一次 1.2s 毛刺。GC 日志Pause Full (G1 Humongous Allocation)每 5 分钟一次——G1 服务本不该有 Full GC。根因分析导出接口一次SELECT *拉 5 万行Jackson 序列化产生 4~8MB byte[]G1 Region 默认 4MB超过一半2MB即 Humongous 对象需连续 Region 存放——高频大对象分配耗尽 Region触发 Full GCA 篇第四章完整案例Q10 深挖。预防方案① 大结果集一律流式/分页与 MySQL 篇深分页同一条军规② 监控规则G1 服务 Full GC 次数 0 即告警③ 大对象多的服务预设 G1HeapRegionSize16m/32m④ 上线前压测覆盖导出类接口。事故解决止血限流导出接口。根治三层业务改分页流式byte[] 8MB→200KB主刀 RegionSize 调 16m缓冲 IHOP 调 35%提前并发标记。验证Full GC 归零P99 回到 90ms。一句话教训G1 的 Full GC 不是内存不够是有东西太大了——看到 Humongous 就去找大对象别去调堆大小。事故二老年代碎片化CMS 深夜连环 Full GC标记-清除的债事故场景JDK 8 CMS 的老服务每天凌晨批处理大量创建释放中等对象后白天随机出现 3~5s 的长停顿。GC 日志concurrent mode failurepromotion failed交替出现随后是 Serial Old 的单线程 Full GC。根因分析CMS 标记-清除不整理 → 老年代碎片化总空闲 40% 但最大连续空闲块只有 2MB批处理晋升的中等对象3~5MB找不到连续空间 → promotion failed → 触发 Serial Old Full GC单线程标记整理3~5s 停顿。碎片是慢性毒药批处理是每天的引爆器A 篇 2.2 算法缺陷Q9。预防方案① 碎片预警-XX:CMSFullGCsBeforeCompactionN配合定期压缩老方案② 根本解迁移 G1Region 间复制天然无碎片③ 批处理错峰 对象生命周期优化临时大对象改分批小对象④ 监控concurrent mode failure关键字告警。事故解决止血凌晨批处理前手动触发一次压缩性 Full GC低峰期主动还债。根治升级 G1JDK 8u292 的 G1 已足够成熟碎片问题彻底消失长停顿归零。一句话教训标记-清除的碎片是分期付款——平时不还大对象来催收时连本带利Serial Old 长停顿。事故三缓存用软引用OOM 前 GC 疯狂空转软引用的陷阱事故场景图片处理服务用SoftReferencebyte[]做内存缓存“内存不足自动释放多优雅”。压测大流量时GC 频率暴涨每秒数次 Full GC、CPU 80% 在 GC、RT 剧烈抖动最后还是 OOM。根因分析软引用的回收时机是内存不足时——但不足的判定发生在 OOM 边缘JVM 先疯狂 GC 试图腾空间GC overhead limit exceeded 的前奏软引用批量释放后业务又立刻重建形成释放-重建-再释放的 GC 风暴。软引用没有容量上限与过期语义它不是缓存方案是OOM 缓冲垫Q2 深挖A 篇 2.1。预防方案① 军规业务缓存禁用软引用一律 CaffeinemaximumSize expireAfterWrite 命中率统计② 需要内存敏感淘汰用 Caffeine 的 weigher 堆水位联动而不是软引用③ 压测必须覆盖缓存满载场景。事故解决迁移 Caffeine上限 500MBweigher 按图片字节数计、10 分钟过期。GC 风暴消失命中率反而从 62% 升到 91%软引用被过早批量释放导致命中率低——第二个隐藏伤害。一句话教训软引用是快淹死时才扔行李——缓存要的是行李清单和载重线容量过期不是救生筏。事故四System.gc() 被 RMI 定时触发每小时一次 2 秒停顿事故场景对接外部系统的服务用了 RMI 导出接口监控显示每小时整点准时出现一次 2s 停顿与业务流量无关规律得像闹钟。根因分析RMI 的 DGC分布式垃圾回收机制默认每小时调用一次 System.gc()清理远程引用sun.rmi.dgc.server.gcInterval默认 3600000ms堆 12G 的显式 Full GC 就是 2s。整点闹钟是 System.gc() 类事故的指纹Q6 深挖。预防方案①-XX:ExplicitGCInvokesConcurrent显式 GC 转为并发执行G1/CMS 下停顿大幅缩短——注意别用 DisableExplicitGC会断 DirectByteBuffer 的 Cleaner 路径堆外泄漏② 用 RMI 就调大 gcInterval 或关闭 DGC③ GC 日志分析时留意与流量无关的规律性 Full GC。事故解决加 ExplicitGCInvokesConcurrent停顿从 2s 降到 50ms 级同时把 RMI 调用改造为 HTTP消灭根因。一句话教训规律得不像事故的停顿多半是有人在定时调 System.gc()——先抓闹钟再查内存。事故五Metaspace 触发 Full GC 风暴Groovy 脚本再立功元空间水位事故场景规则引擎服务Groovy 动态脚本启动后前 10 分钟连续 5 次 Full GC每次日志原因都是Metadata GC Threshold之后趋于平静但类加载数持续上涨一周后 OOM: Metaspace与内存篇事故二同源本篇看 GC 视角。根因分析MetaspaceSize 默认 ~21MB 是首次触发 Full GC 的水位不是初始大小应用类元数据很快超过 21MB → Full GC 尝试卸载类 → 卸载不多 → 水位上调 → 再超再 GC……启动期的 Full GC 风暴就是水位反复试探而脚本持续生成新类一周后触顶 MaxMetaspaceA 篇 2.3 触发条件②内存篇事故二。预防方案①-XX:MetaspaceSize256m直接设到应用稳态水位之上消灭启动期试探性 Full GC② MaxMetaspaceSize512m 设硬上限早暴露③ 动态类生成必须缓存编译结果内存篇事故二的根治方案④ 监控 jvm_classes_loaded 增长斜率。事故解决MetaspaceSize 调 256m启动期 Full GC 从 5 次归零。类加载泄漏按内存篇方案根治脚本 hash 缓存。一句话教训MetaspaceSize 不是初始大小是报警水位——水位设太低JVM 就用 Full GC 反复试探给你看。三、事故速查表现象可能根因快速定位根治方案G1 服务出现 Full GCHumongous 分配 / 晋升失败 / 元空间GC 日志原因字段大对象流式化 / RegionSize 调大 / IHOP 调低concurrent mode failureCMS并发清除赶不上晋升 / 碎片GC 日志 老年代连续空间迁移 G1与流量无关的规律性 Full GCSystem.gc()RMI/NIO 定时停顿时间规律性ExplicitGCInvokesConcurrent启动期连续 Full GCMetadata GC ThresholdMetaspaceSize 水位太低GC 日志原因字段MetaspaceSize256mGC 频繁 CPU 高 最终 OOM软引用缓存风暴 / 无界缓存histo 看软引用/集合规模Caffeine 容量过期回收后老年代占用持续爬升内存泄漏dump MAT GC Roots 链修引用链static/ThreadLocal/监听器Young GC 每秒多次Eden 太小 / 分配速率过高GC 日志频率 晋升量调大新生代 / 减少临时对象GC 日志停顿短但业务卡顿长TTSP 长可数循环无安全点-Xlog:safepointUseCountedLoopSafepoints / 改循环容器 exit 137 且 GC 正常堆外泄漏GC 管不到NMT / RSS-堆差值MaxDirectMemorySize Netty 泄漏检测四、面试答题万能框架被问GC/内存问题① 先定框架再展开 判死→算法→收集器→调优 30秒电梯版先给结论② 按面试官兴趣深挖 追问原理:GC Roots/SATB/染色指针 追问实战:GC日志三指标事故案例③ 落到生产视角 调优先问业务目标:吞吐型还是延迟型90%的GC问题根因在代码不在参数④ 用案例收尾 Humongous大对象/整点System.gc闹钟有画面感的事故胜过一切背书加分技巧谈 ZGC 主动讲染色指针看指针就知道对象状态 读屏障自愈Q11——原理级理解谈 STW 主动带 TTSP 与安全点Q7——90% 候选人只知道停顿GC 干活时间谈调优先说目标分吞吐型/延迟型参数相反Q13——架构思维被问遇到过什么 GC 问题用事故一Humongous或事故四整点闹钟——有画面感的案例胜过一切背书。五、与 A 篇的知识点映射本篇题目/事故A 篇《垃圾回收机制详解》对应章节Q1 可达性分析/GC Roots2.1Q2 四种引用2.1 引用强度表Q3 finalize2.1延伸Q4 逃逸分析/栈上分配《JVM内存模型与对象详解》3.3本文 2.2 分代与分配的前提Q5 四大算法2.2Q6 GC 类型与触发2.3Q7 STW/安全点2.3 STW 段Q8 收集器演进第一章时间线Q9 CMS2.4 CMS 段Q10 G12.4 G1 段 3.3Q11 ZGC2.4 ZGC 段Q12 选型实践3.1/3.2Q13 调优步骤2.5 GC 日志 3.3Q14 参数模板3.1联动内存篇 3.1/3.2Q15 排查 SOP第四章实战事故一 Humongous第四章完整案例事故二 CMS 碎片2.2 标记-清除 2.4 CMS 缺陷①事故三 软引用风暴2.1 软引用行事故四 System.gc()2.3 触发条件③事故五 Metaspace 水位2.3 触发条件②结语GC 面试的尽头是权衡意识——复制算法用空间换速度、CMS 用碎片换并发、ZGC 用吞吐换停顿、G1 用内存开销换可预测性。每个收集器都是一组取舍的答案说出它放弃了什么比说出它得到了什么更显功力。配套阅读上一篇《01-03-A-JVM内存模型与对象详解.md》A 篇《01-04-A-垃圾回收机制详解.md》下一篇《01-05-A-类加载机制详解.md》如果这篇文章对你有帮助欢迎点赞、收藏、关注