并发标记失败是G1或CMS在并发标记阶段因老年代空间不足或碎片严重而中止并退化为Full GC的明确信号，主因是大对象（如DTO、缓存实体）体积失控导致晋升突增或Humongous分配；需结合GC日志、TLAB降级计数及堆分析定位体积异常点，并将核心DTO单实例控制在64KB以内。
并发标记失败（Concurrent Mark Failure）不是GC日志里的普通警告，而是G1或CMS在并发标记阶段因老年代空间不足或碎片严重而被迫中止、退化为Full GC的明确信号。它不直接说“对象太大”，但背后往往藏着业务对象体积失控——尤其是高频创建、长生命周期、未合理拆分的核心DTO或缓存实体。
看懂并发标记失败背后的体积线索
这类失败在G1日志中常表现为：“Concurrent mark abort” 或 “Concurrent marking aborted due to space exhaustion”；在CMS日志中则对应 “concurrent mode failure”。关键要关注失败发生时的上下文：
- 失败前一次Young GC后，晋升到老年代的对象大小是否突增（比如从平均2MB跳到8MB）？说明有批量大对象正在“闯关”；
- 失败时刻的老年代已用空间是否未达阈值（如才65%），但可用连续空间极小？这暗示对象体积过大，导致Region无法容纳，是巨型对象（Humongous Object）的典型征兆；
- 日志中是否伴随 “Humongous allocation” 记录？G1将大于Region一半的对象视为巨型对象，直接分配在Humongous Region中，极易引发标记失败和内存浪费。
关联业务代码定位体积异常点
不能只盯日志，要让JVM行为与业务逻辑对齐：
- 筛选失败时段内高频创建的对象类名：用 -XX:+PrintAdaptiveSizePolicy + -XX:+PrintGCDetails 结合 jstat -gc <pid> 观察晋升对象的Class Histogram（需配合堆转储或Arthas）；
- 重点排查三类高危对象：含大量List/Map字段的DTO（如OrderWithItemsDTO）、未压缩的JSON字符串缓存、Base64编码的二进制附件字段；
- 检查是否有“隐式膨胀”：比如一个UserDTO里嵌套了UserProfile、AddressList、PreferenceMap、RecentOrders（含完整OrderItem列表），实际序列化后超2MB——这种设计在压测中会立刻暴露。
用TLAB降级计数器交叉验证
并发标记失败常与TLAB降级分配共现。因为大对象绕过TLAB直接分配，加剧Eden区压力，加速YGC频率，进而推高晋升速率。此时可开启：
- -XX:+PrintTLAB 查看TLAB waste与refill次数；
- -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=vm.log 捕获 TLABAllocationStalls 计数；
- 若该计数在并发标记失败前后同步激增，基本锁定问题不在GC策略，而在对象本身尺寸失控。
验证与收敛：体积健康度的量化锚点
所谓“健康”，不是越小越好，而是匹配业务语义与分配节奏：
- 核心DTO单实例体积建议控制在64KB以内（G1默认RegionSize=2MB时，可容纳32个）；
- 避免单个对象 > 1MB，否则大概率触发Humongous分配，且无法被G1常规回收路径高效处理；
- 压测中若并发标记失败频次 > 1次/小时，且伴随TLAB降级计数增长 > 300%，应立即启动DTO字段裁剪、懒加载改造或分页/流式序列化。
