Java用可达性分析判断对象是否可回收：从GC Roots出发，不可达即回收；GC分标记、清除、整理三步；触发条件包括Eden满（Minor GC）、老年代不足（Full GC）等；新生代多用复制算法，老年代用标记-整理或标记-清除。
GC怎么判断一个对象该被回收
Java不靠引用计数，而是用可达性分析算法：从一组固定的 GC Roots 出发，顺着引用链往下找。只要对象和任意一个 GC Roots 之间还连着，就认为它“活着”；断了，就是垃圾。
常见的 GC Roots 包括：
- 虚拟机栈 中正在使用的局部变量引用的对象
- 方法区 中的静态变量（static 字段）和常量（如 String.intern() 结果）
- 本地方法栈 中 JNI 引用的对象
- 正在运行的 Java线程 本身
⚠️ 注意：循环引用的对象，只要没被任何 GC Roots 连上，照样会被回收——这是引用计数法做不到的。
GC实际执行分哪几步
主流收集器（如 Serial、G1、ZGC）逻辑上都包含三个阶段，但具体是否执行整理，取决于算法和代际：
-
标记（Marking）：遍历所有
GC Roots，递归标记所有可达对象 - 清除（Sweeping）：回收未被标记的对象所占内存
-
整理（Compacting）：把存活对象往内存一端挪，消除碎片（如
Serial Old、G1 Mixed GC会做；而CMS不做，所以容易产生碎片）
新生代多用 复制算法（Eden → Survivor），快且无碎片；老年代倾向 标记-整理 或 标记-清除+记忆集（如 G1），兼顾吞吐与停顿。
立即学习“Java免费学习笔记（深入）”；
什么情况下会触发GC
GC不是定时任务，而是由 JVM 根据堆状态动态决定的。最常见触发场景有：
-
Minor GC：当Eden区没空间分配新对象时立即触发（最频繁） -
Full GC：老年代空间不足、System.gc()被调用（仅建议）、Metaspace扩容失败、CMS 失败后兜底等 - 低负载空闲期：JVM 可能主动发起 GC，提前释放内存（非强制）
- 直接内存告警：虽然 GC 主管堆，但
DirectByteBuffer耗尽也可能间接触发Full GC
⚠️ System.gc() 是提示，不是命令；JVM 完全可以忽略。生产环境应禁用该调用，避免干扰自动调度。
不同代用什么回收器，为什么不能混搭
JVM 默认按分代组织堆（Young Gen / Old Gen），每代对应专用收集器：
- 新生代：常用
Parallel Scavenge（JDK8默认）、ParNew（配合 CMS）、G1的年轻代回收 - 老年代：
Parallel Old（吞吐优先）、CMS（已弃用，JDK14移除）、G1（整堆管理，含老年代） - 组合限制严格：比如
-XX:+UseParNewGC必须配-XX:+UseConcMarkSweepGC，否则启动报错；G1是整堆收集器，不区分年轻/老年代收集器参数
查看当前生效的收集器：启动时加 -XX:+PrintCommandLineFlags，或运行中用 jinfo -flag +PrintGCDetails <pid>。
真正难的不是知道流程，而是理解「为什么一次 Minor GC 后对象没进老年代，下一次却突然晋升」——这背后是 Survivor 区动态年龄阈值、空间担保失败、大对象直接分配等隐式策略，调试时得结合 -XX:+PrintGCDetails 和堆转储才能定位。
