gc在java中原理分析
Java垃圾回收本质是自动管理堆内存，通过可达性分析（以GC Roots为起点）判定对象存活，按分代理论将堆分为新生代（Eden+S0/S1）和老年代，分别采用复制、标记-清除/整理算法回收；Minor GC在Eden满时触发，Full GC在老年代不足等情况下触发。
Java 中的垃圾回收（GC）本质是自动管理堆内存，识别并回收不再被引用的对象，释放空间供新对象使用。核心在于判断“哪些对象可被回收”，以及“何时、如何回收”。
对象存活判定：可达性分析
Java 不采用引用计数法（因无法解决循环引用），而是基于可达性分析（Reachability Analysis）：以一组称为“GC Roots”的对象为起点，向下搜索引用链；所有能被这条链触及的对象视为“存活”，其余即为可回收对象。
常见的 GC Roots 包括：
- 虚拟机栈（栈帧中的局部变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象（如字符串常量池里的引用）
- 本地方法栈中 JNI（即 Native 方法）引用的对象
分代收集理论：按对象生命周期分区域处理
HotSpot 虚拟机将堆分为新生代（Young Gen）和老年代（Old Gen），依据是“绝大多数对象朝生夕灭”的经验规律。
新生代进一
步划分为 Eden 区 + 两个 Survivor 区（S0、S1）。对象优先分配在 Eden；一次 Minor GC 后，存活对象进入 Survivor；经历多次 Minor GC 仍存活（默认 15 次，由 -XX:MaxTenuringThreshold 控制），则晋升至老年代。
这种划分让 GC 更高效：新生代用复制算法（快、无碎片），老年代用标记-清除或标记-整理（空间利用率高）。
GC 算法与常见收集器
不同代采用不同算法：
- 复制算法（Copying）：用于新生代。暂停应用线程（STW），将 Eden 和一个 Survivor 中存活对象复制到另一个 Survivor，清空原区域。简单高效，但牺牲一半 Survivor 空间。
- 标记-清除（Mark-Sweep）：用于老年代（如 CMS 的初始实现）。先标记所有存活对象，再清除未标记对象。缺点是产生内存碎片，可能触发 Full GC。
- 标记-整理（Mark-Compact）：如 Serial Old、G1 的 Full GC 阶段。标记后将存活对象向一端移动，再清理边界外内存。避免碎片，但移动成本高。
主流收集器如 G1、ZGC、Shenandoah 已不再严格按分代，但依然依赖可达性分析 + 增量/并发标记等机制来降低 STW 时间。
触发 GC 的典型时机
GC 不是定时执行，而是由内存压力驱动：
- Eden 区满时触发 Minor GC（最频繁）
- 老年代空间不足，或 Minor GC 后晋升失败，触发 Full GC（代价高，应尽量避免）
- 元空间（Metaspace）满、System.gc() 显式调用（仅建议）、堆内存扩容失败等也可能触发
可通过 -XX:+PrintGCDetails -Xloggc:gc.log 查看 GC 日志，分析频率、停顿、回收效果。
基本上就这些。GC 的设计是在吞吐量、延迟、内存占用之间做权衡，理解原理有助于合理调参、定位 OOM 或频繁 GC 问题，而不是盲目调大堆或禁用 System.gc。
