Java垃圾回收需理解对象生死逻辑、内存分区行为并动手验证，核心是建立“对象何时死、JVM怎么判、GC怎么收、问题怎么调”闭环；GC Roots包括栈帧变量、静态字段、常量池字面量和JNI引用，仅当对象不可达Roots时才被回收；堆分新生代（Eden/Survivor）和老年代，Minor GC频繁快（复制算法），Major/Full GC少见但停顿长（标记-整理）；须用-XX:+PrintGCDetails等参数及jstat、VisualVM工具观察GC日志与内存变化；典型问题如频繁Minor GC、老年代缓慢增长、单次停顿过长，对应调优策略为扩容Eden、引入LRU缓存淘汰、切换G1/ZGC等。
Java 垃圾回收不是靠背概念通关的，而是靠理解对象生死逻辑、看清内存区域行为、动手验证回收时机。核心在于建立“对象何时死、JVM怎么判、GC怎么收、问题怎么调”的闭环认知。
搞懂 GC Roots 和对象“死亡”判定
对象是否被回收，不看它有没有变量名，而看它能否从 GC Roots 被访问到。GC Roots 就是 JVM 认定的“绝对活跃起点”，包括：
- 栈帧里的局部变量（比如方法里 new 出来的对象引用）
- 类的静态字段（public static Object cache）
- 常量池中的字符串字面量（如 "hello"）
- 正在执行的本地方法（JNI）持有的对象
只要一条引用链能连到 Roots，对象就“活着”；断了，哪怕还有其他对象互相引用（循环引用），也会被回收。这是可达性分析的本质——它不数引用次数，只看路径通不通。
分清新生代和老年代的回收逻辑
堆内存不是一块铁板，而是按对象年龄分区管理：
立即学习“Java免费学习笔记（深入）”；
- Eden 区：新对象出生地，98% 的对象在这里创建、也在这里“夭折”
- Survivor 区（From/To）：熬过一次 Minor GC 的对象搬进来，每活一轮年龄 +1
- 老年代：年龄达阈值（默认 15）或大对象（如超大数组）直接进去
Minor GC 频繁但快（复制算法），Major GC（或 Full GC）少见但停顿长（标记-整理）。练的时候重点观察：哪些操作会触发 Minor GC？哪些会让对象提前进老年代？比如分配一个 4MB 数组，在默认 8MB Eden 下很可能直接进老年代，绕过 Survivor。
用工具把 GC 过程“看见”
光读原理容易飘，必须配合 JVM 参数和日志实操：
- 加参数启动：
-XX:+PrintGCDetails -Xloggc:gc.log，跑一段含集合扩容、大对象创建的代码，看日志里 Eden 使用率、GC 类型、耗时、前后内存变化 - 用
jstat -gc <pid>实时监控各代内存使用和 GC 次数 - 用 VisualVM 或 JConsole 连接运行中的程序，直观看到堆内存曲线和 GC 时间点
例如，反复往 ArrayList 添加元素，观察 Eden 区如何快速填满并触发 Minor GC；再故意让一个大 byte[] 不释放，看老年代如何缓慢增长，最终触发 Full GC。
识别典型 GC 问题并动手调优
真实场景中，GC 问题往往表现为：
- 频繁 Minor GC → 可能 Eden 太小，或代码在循环里无节制创建短命对象
- 老年代缓慢上涨 → 可能有缓存没设淘汰策略，或静态集合不断 add
- 单次 GC 停顿过长（>1s）→ 可能老年代太大且碎片多，或用了 Serial 收集器处理大堆
调优不是乱调参数，而是有针对性动作：比如发现大量 String 临时拼接，改用 StringBuilder；发现 Map 缓存无限增长，加上 LRU 或过期机制；确认业务允许低延迟后，换成 G1 或 ZGC 收集器并设置 -XX:MaxGCPauseMillis=200。
