Minor GC由Eden区空间不足直接触发，一填满即回收；新对象分配时Eden无足够连续空间便立刻执行，Survivor区满、老年代剩余空间等均不构成触发条件。
Minor GC 是由新生代 Eden 区空间不足直接触发的，不是定时或按对象数量，而是“一填满就回收”。
Eden 区满是唯一明确触发条件
新对象默认分配在 Eden 区。当 JVM 尝试为新对象分配内存，发现 Eden 区没有足够连续空间时，**立刻触发 Minor GC**。Survivor 区是否已满、老年代剩余多少，都不会单独引发 Minor GC。
- 哪怕 Eden 只差一个字节放不下新对象，也会触发一次 Minor GC
- Minor GC 不会因为 Survivor 区快满而提前发生
- 它也不关心对象年龄是否接近阈值——年龄只影响后续处理（如晋升），不决定是否触发
Minor GC 的实际执行过程
触发后，JVM 执行以下动作：
- 标记 Eden 区和当前 From Survivor 区中所有可达（存活）对象
- 将存活对象按年龄判断去向：未达阈值的复制到 To Survivor 区；已达阈值或过大，则直接晋升至老年代
- 若 To Survivor 空间不够容纳全部存活对象，多余部分直接担保晋升到老年代
- 清空 Eden 和 From Survivor 区所有内容（包括垃圾和已复制对象）
- 交换 S0/S1 角色，为下一次 Minor GC 做准备
哪些情况看似相关，但其实不触发 Minor GC
有些现象容易被误认为是 Minor GC 的诱因，实际并非如此：
- 大对象直接进老年代：当对象大小超过 -XX:PretenureSizeThreshold 设置值，它会跳过 Eden，直接在老年代分配——这不会导致 Eden 满，也不会触发 Minor GC
- Survivor 区空间紧张：只是影响复制阶段的“去留”决策，不构成触发条件
- 老年代快满了：它可能让 Minor GC 后的晋升失败，从而间接引发 Major GC 或 Full GC，但不影响 Minor GC 本身的触发
Minor GC 频繁可能说明什么
如果 Minor GC 非常频繁（比如一秒多次），通常反映：
- Eden 区设置过小（-Xmn 或 -XX:NewRatio 配置不合理）
- 应用创建大量短生命周期对象（如循环内反复 new byte[]、String 等）
- 存在隐式对象生成（如正则匹配、JSON 解析、字符串拼接等产生临时对象）
