最小化长任务GC停顿的核心是将大STW切碎、推后并并发执行：增量标记按帧扫描对象（单次0.5~2ms），依赖三色模型与写屏障保障一致性；并发回收由专用线程后台清理，G1通过-XX:MaxGCPauseMillis=100–200ms动态调控Region回收，兼顾延迟与吞吐。

要最小化长任务中的 GC 停顿，核心不是消灭停顿，而是把原本一次几百毫秒的 STW（Stop-The-World）切碎、推后、并让大部分工作与业务线程同时跑——增量标记负责“拆”，并发回收负责“并”，二者配合才能真正压低感知延迟。

用增量标记把大标记动作切成“呼吸间隙”

标记阶段不再等应用暂停后再一口气扫完所有对象，而是按帧或按任务切片：每次只扫描几十到几百个灰色对象，标黑自身、标灰子对象，然后交还 CPU 给业务逻辑。它依赖三色模型维持中间状态一致性，即使被中断也能恢复。

• 在 V8 或 G1 中，这个过程常嵌入事件循环空闲期或两次动画帧之间
• 当内存分配速率上升时，系统会自动加快切片节奏，但单次耗时仍控制在 0.5~2ms 内
• 必须配合写屏障：一旦黑色对象新增指向白色对象的引用，就立刻把该白色对象“拉回”灰色队列重新扫描，防止漏标

靠并发回收让清理工作不抢主线程时间

标记完成后，真正的对象移动、压缩、清空等操作，不再等到 STW 才开始，而是由专用 GC 线程在后台持续运行。用户线程照常分配、读写、执行，GC 线程同步追踪变化、搬运存活对象、更新引用。

• CMS 是“并发标记 + 并发清除”，但无法整理内存，易碎片化
• G1 是“并发标记 + 并行复制”，每次只回收部分 Region，兼顾可控停顿和空间利用率
• ZGC/Shenandoah 更进一步，连对象复制和重映射都做成并发，STW 仅剩几微秒，适合车载、金融等硬实时场景

选对回收器并设准目标，比调参数更重要

算法再先进，也得落在合适载体上。G1 是当前最均衡的选择：它不强制固定周期，而是基于堆使用率（默认 45%）触发并发标记，并根据 -XX:MaxGCPauseMillis 的目标动态决定本次回收多少 Region。

• 设 50ms 目标会导致 GC 过于频繁，吞吐暴跌；设 1000ms 又失去低延迟意义，推荐 100–200ms 区间起步
• 避免手动干预年轻代大小，G1 会自动伸缩；但可调 -XX:G1HeapRegionSize（如 2MB）来平衡 Remembered Set 开销与扫描精度
• 观察 G1 Evacuation Pause（真正 STW）和 Concurrent Cycle（后台耗时）的分布，而非只盯 GC 次数

真正卡住停顿的，往往是应用行为本身

再好的 GC 策略，也扛不住突发的大对象分配、过早晋升、或老年代里长期持有一个不该存在的强引用。这些会直接破坏增量/并发的前提假设。

• 监控 Humongous Region 分配频率，高频说明有超大临时缓冲区（如未分块的 JSON 解析）
• 检查对象晋升年龄，若 Survivor 区刚用几次就被塞满，说明 -XX:MaxTenuringThreshold 设得太小或 Eden 太小
• 用 jstat -gc 或 GC 日志分析 Promotion Rate 和 Old Gen 使用趋势，定位是否由数据倾斜或缓存滥用引发