根本解法是打破同步模型，采用SAGA或事件驱动异步编排，配合分层超时、幂等重试与GC感知熔断。
分布式长事务编排中，GC 停顿引发 RPC 超时、继而触发重试、最终演变为雪崩，本质是“时间不确定性”撞上了“强同步假设”。解决不能只盯着 GC 调优，得从调用模型、超时设计、重试语义三个层面协同破局。
识别并隔离 GC 敏感环节
长事务编排常把多个 RPC 串成线性流程（如：A→B→C→D），其中任意一环卡住都会拖垮整条链。而 JVM Full GC 或长时间 STW（尤其是 G1/CMS 在大堆场景下）极易让一次 RPC 等待突破超时阈值。
- 避免在关键路径上做高 GC 压力操作：比如序列化大对象、频繁创建临时集合、日志打印全量请求体等，这些应前置过滤或异步化
- 将编排逻辑与执行逻辑解耦：用状态机 + 消息驱动替代纯同步调用。例如，A 完成后发 MQ 通知 B，B 消费后更新自身状态并回调 A —— 这样即使 B 因 GC 延迟几秒，也不会阻塞 A 的线程和事务上下文
- 对核心服务启用 ZGC 或 Shenandoah：它们的 STW 控制在 10ms 级别，显著降低超时误判概率；同时监控 G1OldGC、PauseTimeMillis、ZGCCycle 等指标，与 RPC 超时阈值形成联动告警
设置带缓冲区的分层超时
单纯把 RPC 超时设为 2s 并不能解决问题——如果 GC 停顿 1.8s，那它刚好卡在临界点，既没被熔断，又反复触发重试。需要给“预期耗时”留出安全缓冲。
- 内部 RPC 调用超时 = 预估 P95 耗时 × 1.5，且上限不超过 800ms；若业务确实慢（如报表导出），走异步轮询，不走同步 RPC
- 在 RPC 客户端层嵌入“软超时”：比如配置硬超时 800ms，但当检测到 JVM 已发生 >500ms GC 时，主动提前 200ms 中断本次调用，直接走降级，不等硬超时触发
- 对长事务编排器本身设置独立超时（如 30s），并开启 cancelable context：一旦某子步骤超时，能快速释放其持有的资源（数据库连接、锁、内存缓存），防止连锁阻塞
重试必须绑定幂等 + 熔断兜底
没有幂等性的重试，等于把 GC 停顿放大为数据错误；没有熔断的重试，等于把局部延迟升级为全局雪崩。
- 所有参与长事务的 RPC 接口，必须实现服务端幂等：基于业务唯一键（如 order_id + action_type）做去重，而不是依赖客户端重试 ID
- 重试次数严格限制为 1 次（最多 2 次），且第二次重试前强制 sleep（如 100ms），避免瞬间重压击穿下游
- 启用熔断器，并以 超时率 + GC 停顿时长双因子 触发：例如连续 10 秒内，超时率 >3% 或单次 GC >300ms 达到 3 次，即熔断该服务，跳过重试，直降级
用异步编排替代同步等待
最根本的解法，是打破“一个线程绑死整个事务生命周期”的模型。长事务天然不适合同步 RPC 编排。
- 采用 SAGA 模式：每个步骤提交本地事务后发补偿指令，失败时反向执行 Cancel；编排器只管状态流转，不阻塞等待
- 引入事件溯源 + 流程引擎（如 Camunda、Temporal）：步骤执行结果通过事件发布，编排器监听事件推进状态；GC 停顿只影响单个 worker，不影响整体流程调度
- 对用户侧屏蔽延迟：前端发起后立即返回“已受理”，后端通过 WebSocket 或消息推送更新进度，避免用户刷新重试
