tlab分配失败会触发慢路径，导致线程争抢allocation lock、eden碎片率升高、minor gc加速，实测吞吐下降5~10倍；需通过-xlog:gc+alloc=debug或-xx:+printtlab定位，关注refill requested频次与waste字段，并结合jstat、async-profiler和jfr进行多维分析。
TLAB 分配失败后走慢路径，不是“多抢一次锁”那么简单，而是直接把线程拖进全局分配竞争队列，同时悄悄抬高 Eden 碎片率、加速 Minor GC 触发——实测吞吐下降 5~10 倍是常态，不是理论值。
怎么确认当前正在发生 TLAB 分配失败
别只盯着 OutOfMemoryError: Java heap space，它和 TLAB 失败基本无关。真要定位，必须开日志：
- JDK 10+：启动加
-Xlog:gc+alloc=debug，grepTLAB allocation failed或refill requested - 旧版 JDK（如 8u292）：用
-XX:+PrintTLAB -XX:+PrintGCDetails，重点看每行的waste字段是否持续 >10%，以及actual_size是否远小于desired_size - 关键点：单次日志没意义，得跑 5 分钟以上真实流量。压测时线程分配节奏被人为拉平，容易漏掉毛刺型失败
慢路径到底在哪儿抢锁、抢什么锁
失败后进入的慢路径，核心是 CollectedHeap::common_mem_allocate_init，它会触发三重开销叠加：
- 必须争
Allocation Lock（HotSpot 里是SharedHeap::_mutator_lock），线程阻塞 + CAS 自旋 + 上下文切换，在 QPS 过万时，refill requested刷屏就是锁竞争已成瓶颈的信号 - 对象不再写入 TLAB 的连续内存块，而是直接落在 Eden 起始位置，破坏
Bump Pointer的指针碰撞连续性，Eden 区碎片率升高 - 大量
humongous allocation出现在 GC 日志里？说明大对象（>TLAB 剩余空间一半）频繁绕过 TLAB，这类分配本身就要 CAS 抢共享内存，且易引发担保失败
如何量化慢路径对 Young GC 的实际反馈影响
不能只看平均 GC 时间，得拆开链路看指标联动：
- 用
jstat -gc <pid></pid>对比EC（Eden 容量）和EU（Eden 已用）：如果EU波动剧烈、GC 频次突增，再结合PrintTLAB里refill次数/秒 > 线程数 × 2，基本可断定 TLAB 成了 GC 触发加速器 - 用
Async-Profiler采样热点：CollectedHeap::common_mem_allocate_init占比若超过 15%，说明慢路径已侵入关键分配路径 - 做对照实验：加
-XX:-UseTLAB关掉 TLAB，实测吞吐下降 30%~50%——这部分就是 TLAB 本该扛住的锁竞争压力，也是它对 GC 频次的隐性缓冲作用
最容易被忽略的毛刺型退化场景
真正难调的不是稳定高分配速率，而是波动性行为：比如某个定时任务线程突然批量 new 几百个中等大小对象，瞬间耗尽 TLAB，但日志里只体现为单次 allocation failed，常规监控完全捕捉不到。这种毛刺会导致局部 Eden 碎片激增、某次 Minor GC 提前触发，但无法归因到具体线程。
必须结合线程级分配采样，例如开启 JFR 事件 jdk.ObjectAllocationInNewTLAB，或用 async-profiler -e alloc 按线程维度抓分配热点，否则这类问题永远在 GC 日志里“隐身”。
