Java GC核心是可达性分析算法：从GC Roots（如栈帧变量、静态变量、JNI引用）出发，不可达对象才可回收；引用计数法因无法解决循环引用被弃用。
Java 垃圾回收（GC）没有标准“百问百答教程”，但掌握核心机制、常见问题和调优思路，比死记硬背问答更有效。关键不是答全一百个问题，而是理解“对象何时可回收”“哪些区域怎么回收”“为什么停顿”“如何看日志”这四条主线。
搞懂 GC 的基本前提：对象怎么才算“死”？
Java 判定对象是否存活，靠的是可达性分析算法，不是引用计数。从 GC Roots（如栈帧里的局部变量、静态变量、JNI 引用等）出发，能触达的对象就活着；不可达的，才可能被回收。
- 即使重写了
finalize()（已废弃），也不保证执行，更不保证能“救活”自己 - 软引用（
SoftReference）在内存不足时才回收；弱引用（WeakReference）下次 GC 就可能消失；虚引用（PhantomReference）仅用于跟踪回收时机，必须配合引用队列使用 - 局部变量没显式置 null，方法结束栈帧销毁后，引用自然消失——多数情况无需手动干预
分清不同垃圾收集器的适用场景
HotSpot VM 提供多种 GC 算法，选错会适得其反：
- Serial / Parallel（吞吐量优先）：单核或后台批处理任务可用；Parallel GC（-XX:+UseParallelGC）适合追求高吞吐、能接受较长 STW 的服务
- CMS（已弃用）：曾为降低停顿设计，但存在并发失败、浮动垃圾等问题，JDK 14 起彻底移除
- G1（默认，JDK 9+）：面向大堆（>4GB）、可控停顿时间（-XX:MaxGCPauseMillis=200），通过分区（Region）实现增量回收
- ZGC / Shenandoah（低延迟首选）：目标是停顿控制在 10ms 内，支持 TB 级堆，ZGC 需 JDK 11+（生产推荐 JDK 17/21），Shenandoah 从 JDK 12 开始内置
看懂 GC 日志，比背参数更重要
加参数启动：-Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 11+ 新日志系统），重点关注：
立即学习“Java免费学习笔记（深入）”；
- GC 类型：Young GC（YGC）、Full GC（FGC）、Mixed GC（G1 特有）
- 耗时与频率：YGC 每秒几次？每次多少毫秒？FGC 是否频繁？一次停顿超 1s 就要警惕
- 内存变化：Eden 区是否总满？老年代是否持续增长？是否有内存泄漏迹象（如 Full GC 后老年代仍居高不下）
- 别只盯着“GC 时间短”，还要看“回收效果”——比如 G1 Mixed GC 回收了几个 Region？是否真正释放了空间？
调优不是乱改参数，而是定位瓶颈再动手
盲目设置 -XX:NewRatio 或 -XX:SurvivorRatio 很少见效。先做三件事：
- 用
jstat -gc <pid></pid>观察 GC 频率与各代占用趋势 - 用
jmap -histo <pid></pid>查看对象数量与大小分布，找异常大或激增的类 - 必要时 dump 堆（
jmap -dump:format=b,file=heap.hprof <pid></pid>），用 VisualVM 或 Eclipse MAT 分析谁占着老年代不放 - 常见误操作：给小应用配 ZGC（反而增加开销）；把 Metaspace 设太大掩盖 ClassLoader 泄漏；关闭 GC 日志导致问题无法复现
不复杂但容易忽略：GC 是 JVM 自动管理的一部分，不是性能瓶颈的万能替罪羊。多数 GC 问题背后，是代码里没关流、缓存无淘汰、监听器未注销、线程池无限堆积等实际逻辑缺陷。
