强制执行full gc会直接引发微服务集群雪崩，因其触发stop-the-world导致线程阻塞、重试风暴、连接池耗尽、服务注册心跳失败及监控自愈机制瘫痪，形成级联故障。
强制执行 Full GC 会直接引发微服务集群雪崩，核心原因在于它在高并发、低容错的临界时刻，人为制造了大规模线程阻塞、响应延迟和资源连锁耗尽——这不是一次“清理内存”的操作，而是一次全局性的服务冻结。
Full GC 的停顿特性在大促场景下被彻底放大
Java 的 Full GC（尤其是使用 CMS 或 G1 在堆压力高时触发）会导致 Stop-The-World（STW），所有应用线程暂停。在日常流量下，一次 500ms 的 STW 可能只影响少量请求；但在大促零点，订单服务每秒处理数万请求，一个节点若因 Full GC 暂停 800ms，意味着： - 数千请求在线程池中排队等待，连接超时不断发生； - 客户端（如网关或上游服务）因未收到响应而启动重试机制； - 重试请求叠加原始请求，形成“重试风暴”，流量翻倍涌向其他节点； - 其他节点因负载陡增，GC 频率进一步升高，STW 更频繁，进入恶性循环。
线程池与连接池被瞬间打满，触发级联阻塞
微服务普遍依赖有限资源池来控制并发，例如： - Tomcat 默认线程池仅 200 线程； - 数据库连接池（如 HikariCP）通常配置 20–50 连接； - Feign/Ribbon 客户端也有连接池和超时限制。 当某服务因 Full GC 卡住，其对外调用全部超时，上游服务的线程持续等待，线程池迅速耗尽；同时，数据库连接无法释放，连接池满后新请求直接失败。此时，熔断器若尚未触发（如失败计数未达阈值），系统就已在无保护状态下承受压力传导。
服务发现与心跳机制同步崩溃，放大故障面
Eureka 等注册中心严重依赖客户端心跳保活。Full GC 发生时： - 服务实例无法按时发送心跳，被注册中心标记为“失联”并下线； - 大量实例几乎同时失联，导致客户端查询返回空列表或极少数健康实例； - 剩余健康节点瞬间承接全部流量，CPU、GC、线程池全面过载； - 这种“批量剔除 + 流量倾泻”现象，正是知识库中指出的“心跳风暴”与服务发现雪崩的典型耦合路径——它让局部 GC 问题演变为全链路服务发现失效。
监控与自愈机制集体失灵
大促期间的自动扩缩容、告警降级、限流开关等防御动作，本身也运行在 JVM 上： - 监控 Agent（如 Prometheus Exporter）可能卡在 GC 中，指标上报中断，告警延迟或失效； - Sentinel 控制台规则下发、Nacos 配置监听等依赖网络 I/O 和线程调度的功能，在 STW 期间完全停滞； - 自动扩容脚本依赖健康检查结果，而健康检查因 GC 超时失败，误判为“需扩容”，却无法真正拉起新实例（因调度平台自身也可能受影响）。 这意味着，系统最需要快速响应的时候，防御体系反而处于“静默瘫痪”状态。
不复杂但容易忽略：Full GC 不是性能问题，而是稳定性雷区。它在大促中从不单独出现，总与线程阻塞、重试风暴、注册中心失联、熔断滞后等环节咬合，成为压垮骆驼的最后一根稻草。
