tlab的“零锁红利”指90%以上对象分配彻底绕过锁，线程仅操作私有缓冲区本地指针，不读写任何共享变量；其核心体现为纳秒级指针碰撞分配、零cas、零内存屏障、零缓存行失效。
TLAB 的“零锁红利”不是降低了锁的粒度，而是让绝大多数对象分配动作彻底不碰锁——线程只在自己那块专属内存里移动指针，全程不读写任何共享变量，自然无需同步。
为什么叫“零锁”，而不是“轻量锁”
没有 TLAB 时，100 个线程同时 new 对象，都要争抢 Eden 区唯一的 top 指针。这个操作必须靠 CAS 自旋或互斥锁完成，失败重试、缓存行失效、上下文切换全都会发生。
启用 TLAB 后：
- 每个线程在 Eden 内拥有独立连续内存段（如线程 A：0x1000–0x1100，线程 B：0x2000–0x2100）
- 分配小对象时，只检查本地 top + size ≤ end，成立就直接 bump 指针（如 0x1050 → 0x1070）
- 整个过程纯寄存器运算，无 CAS、无锁指令、无内存屏障
- 不同线程地址空间完全隔离，零共享、零冲突
红利体现在哪几个关键环节
90% 以上的对象分配因此降级为纳秒级操作，性能提升不是线性，而是数量级跃迁：
- 分配延迟归零：从微秒级（含 CAS 重试）降到单次指针加法，通常
- 竞争面压缩到极致：锁只在 TLAB refill 时才可能触发，频率约为每几千次分配一次
- 硬件友好：避免缓存行伪共享（false sharing），CPU 不再频繁使其他核心缓存失效
- GC 友好：TLAB 内对象天然局部性高，Young GC 复制阶段更易命中 CPU 缓存
红利不兑现的常见信号
TLAB 默认开启，但红利是否真实落地，得看运行时表现：
- slow_allocations 比例高（GC 日志中 >5%）→ 频繁 fallback 到共享 Eden，说明 TLAB 太小或对象偏大
- refill_waste 持续 >1% Eden 总容量 → TLAB 过大，造成内存浪费和 Eden 碎片化
- 日志中几乎无 TLAB 行输出 → 可能被 -XX:-UseTLAB 关闭，或某些 GC 算法（如 ZGC 旧版本）默认抑制日志
- 大对象或逃逸分析成功对象不走 TLAB 是正常行为，不等于红利失效
真正要盯住的核心指标
不用调参数，先看 GC 日志里的三个数字：
- TLAB allocation failed：失败次数多，说明当前 TLAB 容量跟不上线程分配节奏
- refill_waste：每次 refill 剩余未用空间，长期超 50KB 就该关注
- slow_allocations：走共享 Eden 分配的次数，是锁竞争实际发生的次数
这些数字比 -XX:TLABSize 更能告诉你红利有没有被吃掉。
