YGC触发的核心条件是Eden区空间不足；当新对象分配时Eden剩余空间不足以容纳该对象（含TLAB失败后尝试共享Eden），即触发Young GC，这是最常见、最直接的触发路径。
YGC触发的核心条件：Eden区空间不足
当新对象分配时，JVM尝试在Eden区分配内存；若Eden区剩余空间不足以容纳该对象（包括TLAB分配失败后尝试共享Eden），就会触发Young GC。这是最常见、最直接的触发路径，不依赖定时器或外部命令，纯由内存分配压力驱动。
显式调用System.gc()可能间接引发YGC
虽然System.gc()默认建议的是Full GC，但具体行为取决于所用垃圾收集器及JVM参数。例如启用-XX:+UseParallelGC或-XX:+UseG1GC时，若年轻代已积压大量对象，JVM可能优先执行YGC来缓解压力，再决定是否继续回收老年代。注意：-XX:+DisableExplicitGC可完全屏蔽该调用，但不推荐在生产环境依赖此机制清理内存。
GC日志与运行时监控可确认YGC实际发生时机
仅靠代码逻辑无法精确预判YGC时刻，必须结合运行时观测：
- 添加-Xlog:gc*:file=gc.log:time,tags,level（JDK 10+）或-XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）捕获真实GC事件
- 关注日志中类似[GC (Allocation Failure) ...]的标记——它明确表示本次YGC由Eden区分配失败触发
- 使用jstat -gc
观察S0C/S1C/EC/EU变化，EU（Eden使用量）突降至接近0即为YGC执行证据
对象分配策略会影响YGC频率和效果
并非所有新对象都只进Eden：
- 大对象（超过-XX:PretenureSizeThreshold设定值）会直接进入老年代，绕过年轻代，不参与YGC
- 长期存活对象经多次YGC后进入Survivor区并最终晋升老年代，Survivor区空间不足（如fr
om区满且无法容纳存活对象）也会成为YGC触发的连带条件
- 开启-XX:+UseTLAB（默认开启）可减少Eden区并发写竞争，但TLAB耗尽后仍需在Eden中分配，同样可能触发YGC
