对象生命周期决定gc介入时机：新生代eden区满触发minor gc，存活对象经survivor区多次复制后晋升老年代；老年代空间不足或元空间不足则触发major/full gc；gc基于可达性分析判定对象是否可回收。
堆中对象的生命周期直接决定GC何时介入——不是按时间，而是按空间占用和引用关系。对象从新生代出生，经历多次Minor GC后若仍存活，才逐步晋升到老年代；一旦失去所有可达引用路径，就成为待回收垃圾。GC是否触发，取决于堆内各区域的实际压力，而非固定周期。
新生代满即触发Minor GC
绝大多数对象在Eden区诞生，当Eden区无足够连续空间分配新对象时，JVM立即启动Minor GC。此时仅扫描新生代（Eden + 一个Survivor），采用复制算法：存活对象被复制到另一个Survivor区（或直接晋升老年代），原Eden和From Survivor被清空。默认Eden:Survivor比例为8:1:1，意味着新生代约90%空间可用于对象分配，剩余10%作为复制缓冲。
- 频繁创建短生命周期对象会加快Eden填满速度，导致Minor GC频发
- 大对象（如超过-XX:PretenureSizeThreshold设定值）可能直接进入老年代，跳过新生代
- Survivor区过小会导致“幸存者”无处存放，被迫提前晋升，加剧老年代压力
老年代空间不足触发Major/Full GC
对象在Survivor区经历多次Minor GC（默认年龄阈值为15，可通过-XX:MaxTenuringThreshold调整）后晋升至老年代。当老年代剩余空间不足以容纳下一次晋升对象，或无法满足大对象直接分配需求时，就会触发Major GC（部分收集器如CMS）或Full GC（如Serial、Parallel）。这类GC耗时显著更长，因需扫描整个老年代并执行标记-整理或标记-清除。
- 频繁晋升通常源于Survivor区太小、对象存活时间长，或Minor GC后仍有大量对象存活
- Full GC还可能由元空间（Metaspace）不足、显式调用System.gc()（仅建议，不保证执行）引发
- 老年代使用率持续高于阈值（如-XX:InitiatingOccupancyFraction设置值）时，G1等增量式收集器会主动启动混合GC
对象存活判定依赖可达性分析
GC不靠“对象用了多久”判断是否回收，而通过GC Roots出发的引用链进行可达性分析。只要对象能被以下任一节点直接或间接引用，就视为存活：
- 虚拟机栈中局部变量表引用的对象
- 本地方法栈中JNI引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量池引用的对象
断开所有引用链（如将引用置为null、离开作用域、容器未清理引用等），对象即进入“可回收”状态，等待下次对应代的GC处理。
常见误判与优化切入点
实际开发中，不少内存问题并非GC不工作，而是对象本不该长期驻留堆中：
- 静态集合类（如static Map）持续添加对象却不清理，导致对象永久强引用，无法进入老年代甚至OOM
- 缓存未设淘汰策略或使用强引用缓存，使本该淘汰的对象一直存活
- 监听器、回调注册后未反注册，形成隐式引用链
- 线程局部变量（ThreadLocal）未remove，造成内存泄漏，尤其在线程池场景下
优化方向不在阻止GC，而在减少无效强引用、合理设置代际比例（-XX:NewRatio）、调整Survivor大小（-XX:SurvivorRatio）及选用匹配业务特征的GC算法（如低延迟选ZGC，吞吐优先选Parallel）。
