并发标记期间业务线程频繁修改对象引用会加剧读写屏障开销，尤其在cms或g1中；需通过jstat、gc日志、async-profiler定位高频引用更新点，并采用栈上分配、批量提交、弱引用及调大satb缓冲区等策略优化。
并发标记期间业务线程频繁修改对象引用关系，会显著加剧读写屏障（read-write barrier）开销，尤其在cms或g1等使用增量更新（incremental update）或satb（snapshot-at-the-beginning）策略的gc器中。这不是gc本身变慢，而是业务逻辑与gc屏障机制发生了隐性冲突。
确认是否真由引用变更触发屏障高频执行
先排除误判：不是所有引用写操作都会触发同等代价的屏障。关键看是否命中“需记录跨代/跨区域引用”的场景：
- 若对象在年轻代，且新引用指向老年代（如YGC后晋升未完成时写入），会触发写屏障记录卡表（Card Table）或原始快照（SATB buffer）；
- 若对象在老年代，且新引用指向另一个老年代对象（如缓存更新、链表重连），在CMS并发标记阶段会触发“增量更新”屏障，将该引用加入mod-union table；
- 用jstat -gc
观察GCT（GC总耗时）与YGCT（Young GC耗时）比例：若YGCT稳定但GCT持续上升，说明老年代标记压力来自并发阶段的引用变动； - 开启-XX:+PrintGCDetails -XX:+PrintReferenceGC，查看日志中是否有大量“Processed X references”或“SATB buffers flushed”提示。
定位高频修改引用的业务代码位置
屏障损耗本质是CPU和缓存开销，需从热点路径入手：
- 用async-profiler采集运行时热点：./profiler.sh -e cpu -d 30 -f profile.html
，重点关注oop_store、update_barrier_set、card_table::dirty_card等符号调用栈； - 检查是否存在“非必要强引用更新”，例如：定时任务反复重建整个缓存Map、消息消费时频繁替换监听器集合、状态机中冗余的parent/child双向引用维护；
- 特别关注ConcurrentHashMap.computeIfAbsent、CopyOnWriteArrayList.set、AtomicReferenceFieldUpdater等看似线程安全、实则每写一次都触发屏障的操作。
减少屏障触发频次的实用改造方式
不追求完全消除屏障，而是在保障语义正确的前提下降低其密度：
- 对仅用于临时计算、生命周期短的对象引用，改用局部变量+栈上分配（配合JVM逃逸分析），避免进入堆内存，自然绕过屏障；
- 将高频小粒度引用更新聚合为批量操作，例如用List
暂存变更，每N毫秒统一提交，减少屏障调用次数； - 对可容忍短暂不一致的场景（如监控指标、统计计数），改用弱引用（WeakReference）或虚引用（PhantomReference），它们不参与GC可达性分析，不触发写屏障；
- 若使用G1，可通过-XX:G1SATBBufferSize=4096适当增大SATB缓冲区，降低flush频率（但注意会增加内存占用）。
验证优化效果的关键指标
不能只看GC时间下降，要交叉验证底层行为是否改善：
-
jstat -gccause
中concurrent-mark阶段的耗时与次数是否收敛； - perf stat -e cache-misses,cache-references,instructions,cycles对比优化前后，L3缓存缺失率是否下降；
- 业务侧P99延迟是否同步降低——若GC时间降了但延迟没变，说明瓶颈已转移到其他环节（如锁竞争或I/O）；
- 观察-XX:+PrintAdaptiveSizePolicy输出，若G1自动调大了Mixed GC触发阈值，说明并发标记压力确有缓解。
