Minor GC 频繁触发且停顿短，由 Eden 区填满驱动，采用复制算法清理年轻代；其频率取决于 Eden 容量、对象分配速率、线程 TLAB 使用情况；高频或长停顿常反映配置不当或代码问题。
Minor GC 的触发频率高、停顿短，主要因为新生代对象“朝生夕死”，Eden 区很快填满；它固定采用复制算法，只作用于年轻代（Eden + 一个 Survivor 区），不涉及老年代或元空间。
触发频率取决于 Eden 区大小与对象分配速率
Minor GC 不是定时发生的，而是由内存分配行为驱动的：只要新对象在 Eden 区无法完成分配，就立即触发。因此实际频率由两个关键因素决定：
- Eden 区容量配置（如 -Xmn 中年轻代占比，或 -XX:NewRatio 控制新老比例）
- 业务代码中对象创建节奏——比如循环内 new 对象、频繁字符串拼接、未复用的临时集合等，都会显著加快 Eden 填满速度
- 线程数量与 TLAB 使用情况：每个线程有独立 TLAB，TLAB 耗尽后回退到 Eden 全局分配，也可能提前触发 Minor GC
复制算法是 Minor GC 的唯一主流实现方式
HotSpot 所有默认收集器（Serial、Parallel、G1 的 Young GC 阶段、ZGC 的部分阶段）对年轻代都使用复制算法，核心逻辑稳定：
- 从 Eden 和当前 From Survivor 区标记存活对象
- 将它们批量复制到空的 To Survivor 区，同时更新对象年龄
- 若 To Survivor 空间不足，或对象年龄已达阈值（默认 15），则直接晋升至老年代
- 复制完成后，Eden 和 From Survivor 被整体清空，From/To 角色互换
高频 Minor GC 往往暴露配置或代码问题
不是所有频繁 GC 都异常，但以下信号值得立刻检查：
- 每秒发生多次 Minor GC：大概率年轻代太小（-Xmn 设置过低），或存在突发性对象洪峰（如批量导入、日志刷屏）
- 单次停顿超过 100ms：可能 Survivor 区过小导致大量对象被迫晋升，加重老年代压力；也可能是大对象绕过 Eden 直接分配失败引发连锁反应
- GC 日志显示 “to-space overflow” 或 “promotion failed”：说明 Survivor 容量或晋升策略不合理，需调整 -XX:SurvivorRatio 或 -XX:MaxTenuringThreshold
不同收集器下 Minor GC 行为略有差异但本质一致
虽然 G1、ZGC、Shenandoah 在整体设计上更激进，但它们的年轻代回收仍遵循分代逻辑和复制语义：
- G1 的 Young GC 仍是复制式，只是把 Eden 和部分 Survivor 放在多个 Region 中管理
- ZGC 和 Shenandoah 的“年轻代视图”回收虽弱化分代边界，但在对象刚分配阶段仍优先在特定区域集中处理，行为效果接近传统 Minor GC
- 无论哪种收集器，只要看到 GC 日志中标记为 “GC pause (G1 Evacuation Pause)”（G1）、“Pause Young”（ZGC）或 “Young GC”（Parallel），就对应分代模型中的 Minor GC 动作
