G1 GC在年轻代执行回收时是否会暂停应用运行？

你看到的技术文章描述完全属实，你此前“仅Full GC会暂停应用、年轻代GC完全不暂停”的认知是错误的。
你使用的Corretto是OpenJDK合规发行版，其搭载的G1垃圾回收器，所有年轻代回收（Young GC）流程都存在Stop-The-World（STW，即暂停所有用户应用线程）的阶段，不存在完全不暂停应用的年轻代GC。 #

• G1的年轻代GC触发时，第一个STW停顿就是文章提到的簿记操作阶段：这个阶段会快速遍历所有GC Roots、标记根直接引用的对象、统计各Region的对象存活基础数据，这个阶段耗时通常极短，多数常规业务场景下仅几毫秒。
• 上述初始簿记阶段不是年轻代GC唯一的停顿点：后续年轻代存活对象的全量标记、Eden区存活对象复制到Survivor区/老年代、回收后内存元数据重置的整个年轻代回收核心流程，全部是STW状态下执行的。G1的设计目标是通过动态调整每次回收的Region数量、自适应调整年轻代大小，把这部分总停顿时间控制在-XX:MaxGCPauseMillis参数设定的目标值附近（该参数默认值为200ms）。
• 不要混淆G1老年代并发标记阶段的逻辑：G1老年代回收周期中，大部分标记工作是和用户线程并发执行的，但流程前后的初始标记、最终标记、回收筛选阶段依然存在STW停顿；而G1触发Full GC时会做全量堆的STW回收，停顿时间通常远长于常规年轻代GC，但这绝不代表年轻代GC没有停顿。

生产环境中年轻代GC停顿超过健康检查超时阈值的情况非常常见，完全可能触发Auto Scaling Group的弹性扩容逻辑。
如果业务对象分配速率过高、年轻代内存配置过大、MaxGCPauseMillis参数设置过高，或者出现突发大对象/批量对象直接晋升老年代的情况，年轻代GC的STW停顿完全可能达到数百毫秒甚至更久，超过服务健康检查的超时时间，让负载均衡/ASG判定服务实例异常。
你可以通过开启GC日志直接定位问题：给JVM配置对应版本支持的GC日志参数，打印每次GC的触发时间、各阶段停顿耗时、内存回收情况，和健康检查失败的时间点做对齐即可确认根因。常规调优方向包括：根据健康检查超时阈值合理调低MaxGCPauseMillis目标值、适当调整年轻代内存占比、排查代码中是否存在突发的大内存分配逻辑。

内容的提问来源于stack exchange，提问作者Selvakumar Ponnusamy