concurrent marking是g1等现代gc在标记阶段采用的并发策略，允许gc线程与用户线程同时运行，但无法完全绕过stw；它仅将全堆遍历拆分为多次短暂停顿（initial mark和remark）与大量并发工作，从而显著降低总体停顿时间。
Concurrent Marking 是什么，它真能绕过 STW 吗
Concurrent Marking 本身不是独立的 GC 算法，而是 G1、ZGC、Shenandoah 等现代收集器在标记阶段采用的并发策略：让 GC 线程与用户线程**同时运行**，从而把原本必须 Stop-the-World（STW）的“全堆遍历”拆成小块，在应用运行间隙完成。但它不能完全消除 STW —— 初始标记（Initial Mark）和最终标记（Remark）仍需短暂暂停，尤其是 Remark 阶段容易因对象引用关系剧烈变化而拉长。
关键点在于：Concurrent Marking 的价值不在于“零停顿”，而在于把标记工作从一次长停顿，变成多次短暂停顿 + 大量并发工作。这对堆内存 ≥8GB 的服务特别有效，因为纯 Mark-Compact（如 Serial Old 或 Parallel Old）会扫描整个老年代，停顿时间随堆大小线性增长。
G1 中 Concurrent Marking 的触发时机与关键参数
G1 是目前最常用且对 Concurrent Marking 控制最精细的生产级收集器。它的并发标记不是固定启动，而是由堆占用率动态触发：
-
-XX:InitiatingHeapOccupancyPercent=45：当整个堆使用率达到 45% 时，G1 启动并发标记周期。默认值是 45，但大数据场景下常设为 30~35，避免等堆快满才开始，导致后续被迫 Full GC -
-XX:MaxGCPauseMillis=200：这个参数直接影响并发标记的激进程度 —— JVM 会据此压缩年轻代、增大并发线程数、提前分割 Region，以腾出更多 CPU 时间给并发标记 - 不要设
-XX:G1MixedGCCountTarget过低（如 1），否则混合回收（Mixed GC）次数太少，老年代碎片堆积后仍会触发 STW 更长的 Full GC
示例配置片段：
-XX:+UseG1GC -XX:MaxGCPauseMillis=150 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1MixedGCCountTarget=8
为什么你启用了 G1 却没看到明显并发标记行为
常见现象是 jstat -gc 输出里 CCSC（Concurrent Cycle Start）极少出现，或 CM（Concurrent Mark）阶段耗时极短 —— 这往往说明并发标记根本没真正跑起来。原因包括：
- 堆太小（
- 对象晋升太快：年轻代过小（
-Xmn设置不合理）或 Survivor 区太小（-XX:SurvivorRatio过大），大量对象直接进入老年代，G1 认为“标记来不及”，转而走退化路径 - 日志没开全：仅用
-verbose:gc看不到并发阶段细节，必须加-Xlog:gc*,gc+marking=debug（JDK 10+）或-XX:+PrintGCDetails -XX:+PrintGCTimeStamps（JDK 8）才能确认 CM 是否执行
ZGC / Shenandoah 比 G1 更适合超大堆？别盲目切
ZGC 和 Shenandoah 确实把并发标记做到更彻底（初始标记 + 最终标记合计通常
- ZGC 要求 JDK ≥ 11（生产推荐 JDK 17+），且 Linux kernel ≥ 4.14；Shenandoah 在 JDK 12+ 内置，但某些容器环境（如旧版 OpenShift）可能禁用其加载机制
- 两者都依赖内存映射技术（color bits / forwarding table），若应用大量使用
Unsafe.allocateMemory或 JNI 直接操作堆外内存，可能干扰其并发标记一致性 - G1 在 16~64GB 堆范围内仍是平衡性最优选择；只有当堆 ≥ 128GB 且延迟要求
真正容易被忽略的是：Concurrent Marking 效果高度依赖对象图稳定性。如果业务中存在高频修改的全局缓存 Map、未清理的监听器引用链、或 ThreadLocal 持有大对象，会极大增加 Remark 阶段重扫工作量 —— 这时候调参不如先查 jmap -histo:live 和 MAT 分析引用路径。
