cms不进行碎片整理，以空间碎片换取停顿时间缩短；其并发标记依赖增量更新机制通过卡表记录引用变更，再由并发预清理和重新标记扫描脏卡补漏，清除阶段仅用空闲列表管理碎片，不移动对象，长期运行易因碎片导致大对象分配失败而触发full gc。
CMS 收集器不进行碎片整理，这是它最核心的设计取舍——用空间碎片换停顿时间缩短。
并发标记：边运行边追踪，靠增量更新补漏
并发标记阶段允许 GC 线程与用户线程同时执行，从初始标记的对象出发，遍历老年代对象图，标记所有可达对象。但用户线程修改引用关系时，可能导致已标记对象“失联”或新对象“漏标”。CMS 采用增量更新（Incremental Update）机制应对：
- 当一个对象的引用被修改（如某字段指向新对象），JVM 会通过卡表（Card Table）将对应内存页标记为“脏”
- 后续的并发预清理和重新标记阶段，会重点扫描这些脏卡区域，确保新增/变更的引用关系被覆盖
- 这种机制避免了全程重扫，大幅压缩了重新标记阶段的 STW 时间
碎片整理：CMS 默认不做，空闲列表管理碎片空间
CMS 基于标记-清除算法，清除阶段只是把未标记对象占用的内存块加入空闲列表（free list），并不移动存活对象、也不压缩内存。这意味着：
- 长期运行后，老年代会出现大量不连续的小块空闲空间
- 即使总剩余空间充足，分配大对象时仍可能因找不到足够连续空间而失败
- 此时 CMS 无法自行整理，只能触发 Full GC（退化为 Serial Old 或 Parallel Old），完成标记-整理，但会带来显著 STW
碎片问题的缓解手段有限且需权衡
虽然 CMS 本身不整理，但可通过参数间接影响碎片行为：
- -XX:+UseCMSCompactAtFullCollection：在每次 Full GC 后强制整理老年代（已废弃，JDK 9+ 不再支持）
- -XX:CMSFullGCsBeforeCompaction=n：每 n 次 Full GC 后做一次压缩（同样已弃用）
- 更现实的做法是调低 -XX:CMSInitiatingOccupancyFraction，提前启动 CMS，留出更多缓冲空间，降低因碎片导致分配失败的概率
- 搭配 ParNew 使用时，控制新生代晋升节奏（如调优 Survivor 区大小、-XX:MaxTenuringThreshold），也能减少大块对象集中进入老年代加剧碎片
本质上，CMS 的设计哲学就是明确放弃整理——它把“低延迟”放在首位，把“内存规整”交给后备方案或运维干预。一旦碎片成为瓶颈，说明它已超出 CMS 最适合的场景。
