Minor GC 在 Eden 区无足够连续空间分配新对象时立即触发，与 Survivor 区、老年代空间及对象年龄无关；其 STW 时间通常为 1–50 毫秒，仅扫描年轻代，高频发生可能影响响应敏感型服务。

Minor GC 的触发时机非常明确：只要 Eden 区没有足够连续空间分配新对象，立刻发生——和 Survivor 区是否空、老年代有没有空间、对象年龄多少都没关系。

Eden 区满是唯一主因

Java 对象默认分配在 Eden 区。当 new 一个对象时，JVM 检查 Eden 剩余空间；不够就直接触发 Minor GC，哪怕 Survivor 还剩 80% 空间、老年代也充足。

• TLAB（线程本地缓冲）用完后 fallback 到 Eden 全局分配失败，同样算“Eden 满”，会触发
• 大对象（超过 -XX:PretenureSizeThreshold）跳过 Eden，直入老年代，不参与 Minor GC 触发逻辑
• Survivor 区满本身不触发 Minor GC；但 Minor GC 过程中若发现 To Survivor 放不下存活对象，会把溢出部分晋升老年代——这时才可能埋下 Full GC 隐患

Minor GC 的 STW 行为与实际影响

每次 Minor GC 都会 Stop-the-World，所有应用线程暂停，直到 Eden + 当前 From Survivor 的标记、复制、清理完成。

• STW 时间通常在 1–50 毫秒之间，取决于存活对象数量和 GC 算法（如 ParNew 比 Serial 快）
• 它只扫描年轻代（Eden + Survivor），不碰老年代、元空间、JIT 代码缓存，所以不会卡住类加载或反射调用
• 高频 Minor GC（比如每 100ms 一次）虽单次停顿短，但累积延迟会影响响应敏感型服务（如网关、实时计算）

常见误判点与调试线索

很多同学看到 GC 日志里 “GC (Allocation Failure)” 就以为是内存泄漏，其实只是正常分配压力；关键要看频率和回收效果。

• 如果 Minor GC 后 Eden 几乎清零、Survivor 使用率稳定、晋升老年代对象很少 → 属于健康状态
• 如果 Minor GC 频繁且每次回收后 Eden 仍残留大量对象 → 可能存在长生命周期对象意外滞留年轻代（比如缓存未及时清理）
• 开启 -XX:+PrintGCDetails 后，关注 “PSYoungGen” 或 “ParNew” 区段的耗时与前后大小，比单纯看“GC次数”更有诊断价值