Java垃圾回收机制解析与GC执行过程

大家好，我们又见面了啊~本文《Java垃圾回收机制详解与GC执行流程》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

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），兼顾吞吐与停顿。

什么情况下会触发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 。

真正难的不是知道流程，而是理解「为什么一次 Minor GC 后对象没进老年代，下一次却突然晋升」——这背后是 Survivor 区动态年龄阈值、空间担保失败、大对象直接分配等隐式策略，调试时得结合 -XX:+PrintGCDetails 和堆转储才能定位。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~