cms低延迟核心在于分阶段并发标记与写屏障协同：初始标记仅stw标记gc roots直连对象（10–100ms）；并发标记靠写屏障记录引用变更，保障准确性；重新标记stw修补变动，耗时取决于并发期引用修改频率；浮动垃圾可容忍，但并发模式失败将触发full gc，需保守设置启动阈值并监控。
要真正掌握CMS的低延迟特性，关键不在“用不用”，而在于理解它如何通过分阶段、带写屏障的并发标记，把停顿压缩到毫秒级。核心变量不是参数本身，而是标记过程里对象状态变化与线程协作的精确控制点。
初始标记：唯一轻量STW，只抓GC Roots直连对象
这一步必须停顿，但只做最窄范围的标记：栈帧里的局部变量、静态字段、常量池引用，以及刚从新生代晋升过来的对象。它不遍历任何引用链，所以耗时稳定在10–100ms。实战中若这步变长，说明GC Roots异常庞大（比如全局缓存引用过多），需检查静态集合或未关闭的资源持有。
并发标记：靠写屏障+增量更新维持一致性
这是CMS低延迟的主干，全程与用户线程并行。但它不是“放任不管”——JVM在每次对象引用赋值时插入写屏障（Write Barrier），一旦发现老年代对象新增指向新对象的引用，就记录到一个“dirty card queue”中。后续重新标记阶段会扫描这些脏卡，用增量更新（Incremental Update）方式把源头对象重新标为灰色，避免漏标。没有写屏障，就无法支撑并发标记的准确性。
重新标记：修补并发期变动，决定停顿长短
这步再次STW，但目标明确：只处理写屏障捕获的变动项，而非全堆扫描。耗时取决于并发标记期间引用变更的频率和幅度。常见优化包括：
• 启用 -XX:+CMSScavengeBeforeRemark，在重新标记前先做一次Young GC，减少跨代引用数量；
• 调大 -XX:ParallelCMSThreads，让重标多线程并行执行；
• 避免在Remark前后高频修改大对象图（如批量更新缓存结构）。
浮动垃圾与并发失败：低延迟的代价边界
CMS允许并发清除阶段产生新垃圾（浮动垃圾），这部分只能等下次GC回收。更危险的是“Concurrent Mode Failure”：如果老年代在CMS运行中被填满，会立刻退化为Serial Old进行Full GC，造成秒级停顿。因此必须严控触发时机：
• 用 -XX:CMSInitiatingOccupancyFraction 把启动阈值设得保守些（如65–75%，而非默认92%）；
• 监控 concurrent mode failure 日志，出现即说明老年代增长过快或CMS跟不上节奏；
• 禁用 -XX:+UseCMSInitiatingOccupancyOnly 可防止JVM自动调整阈值，保持行为可预测。
