TLAB本质是用空间换时间，为每个线程在Eden区动态划分独立缓冲区，使90%以上对象分配退化为一次指针加法；其通过top/end指针实现无锁、无CAS、零共享的纳秒级分配，仅在TLAB耗尽、对象过大或显式禁用时回退至全局同步分配。

TLAB（Thread Local Allocation Buffer）是 JVM 为每个线程在 Eden 区内划出的一块私有内存缓冲区，它的核心作用不是“省空间”，而是“省锁”——绕过多线程竞争，让对象分配从全局同步变成线性指针移动，从而大幅提升吞吐量。

TLAB 怎么工作：一次 new 背后的快速路径

当线程执行 new 操作时，JVM 优先尝试在本线程的 TLAB 中分配：

• 若 TLAB 剩余空间 ≥ 对象大小，直接 bump-the-pointer（指针碰撞）完成分配，无锁、无 CAS、毫秒级
• 若剩余空间不足但大于预设“最大浪费阈值”，则放弃当前 TLAB，在 Eden 区分配，并触发一次 TLAB refill（重新申请一块）
• 若对象本身过大（超过 TLAB 容量或设定阈值），跳过 TLAB，直接在 Eden 区分配（慢速路径）

TLAB 大小不合理会悄悄拖垮 GC

TLAB 不是越大越好，也不是越小越安全，它和 GC 行为紧密耦合：

• TLAB 过大 → 单个线程独占 Eden 区碎片多，Eden 实际可用率下降，Minor GC 触发更频繁
• TLAB 过小 → refill 频繁，每次 refill 都需同步申请 Eden 空间，增加 Eden 区锁争用和分配延迟
• TLAB 浪费率高（如大量小对象后剩余空间无法利用）→ JVM 自动填充 filler object 占位，虽不泄漏，但挤占有效空间，间接抬高 GC 压力

如何观察与调优 TLAB

TLAB 默认开启（HotSpot 1.6+），无需显式启用，但可通过参数干预行为：

• -XX:+UseTLAB（默认开启，一般不建议关闭）
• -XX:TLABSize：手动指定初始大小（慎用，易破坏自适应逻辑）
• -XX:TLABWasteTargetPercent：控制 refill 触发前允许的最大浪费百分比（默认1%，过高会加剧碎片）
• -XX:+PrintTLAB：输出每次 refill 和 waste 统计，用于诊断分配模式是否异常

生产环境更推荐依赖 JVM 自适应机制（-XX:+ResizeTLAB），配合 GC 日志（-Xlog:gc+allocation=debug）观察 Eden 分配失败率和 TLAB refill 频次，再针对性调整。

TLAB 与 Survivor 区、晋升逻辑的隐性关联

TLAB 只影响分配起点，不改变对象生命周期规则，但它会放大某些 GC 行为的影响：

• TLAB 分配的对象仍遵循年龄计数器机制；若因 TLAB refill 不均导致某线程短期创建大量对象，可能集中触发 Minor GC，使一批年轻对象“扎堆”进入 Survivor 或直接晋升
• TLAB 减少分配竞争，间接降低 GC 前 Eden 区对象分布的随机性，使 Survivor 区复制更有序，但若 Survivor 空间不足，动态年龄判定可能提前将整批对象推入老年代
• 大对象绕过 TLAB 直接进 Eden，若其尺寸接近 Eden 容量，极易引发 Promotion Failure，进而触发 Full GC（尤其在 CMS 或 ZGC 早期版本中）