TLAB是JVM在Eden区为每个线程预分配的私有缓冲区，通过无锁指针碰撞实现小对象纳秒级分配，仅在耗尽、对象过大或Eden不足时退化为全局同步分配，从而彻底规避多线程竞争。

垃圾回收器本身不负责对象分配，它只负责回收；对象分配是 JVM 内存管理的前端行为，发生在堆的 Eden 区，而 TLAB 正是为了解决这个阶段的多线程竞争问题。

TLAB 是分配环节的优化，不是 GC 环节的机制

GC 的职责是识别并清理不可达对象，它不参与 new 操作那一刻的内存划拨。真正发生竞争的地方，是 100 个线程同时调用 new 时，都要往 Eden 区同一块共享内存里“抢位置”。没有 TLAB，就得靠 CAS 或锁同步移动全局分配指针（top），极易成为瓶颈。

TLAB 的作用，就是在 Eden 区内为每个线程预划一块私有小空间。线程分配小对象时，只检查自己那块区域是否够用，够就直接 bump-the-pointer（指针加法），全程无锁、无共享、无同步原语介入。

TLAB 如何让 GC 更“省心”

TLAB 不改变 GC 的逻辑，但间接优化了 GC 行为：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

立即学习“Java免费学习笔记（深入）”；

• 分配更集中有序：同一线程的对象在内存中连续布局，提升 Survivor 区复制效率（复制算法依赖局部性）
• 降低 Eden 锁争用频次：TLAB refill（重新申请）远少于每次 new 都抢锁，减少了分配路径上的同步开销
• 减少无效碎片干扰：虽然 TLAB 浪费会填充 filler object，但相比频繁 CAS 失败导致的缓存行失效和线程调度延迟，整体更可控

哪些情况会绕过 TLAB，重新触发竞争

TLAB 只覆盖高频小对象路径。以下情形会退回到共享 Eden 区分配，此时需同步操作：

• 当前 TLAB 剩余空间不足放下该对象
• 对象大小超过 JVM 启发式阈值（通常约 2–4KB，与 -XX:MaxTLABSize 相关）
• Eden 区已满，无法成功 refill 新 TLAB
• 显式关闭 TLAB（-XX:-UseTLAB，不推荐）

TLAB 和 GC 日志怎么配合看效果

观察 TLAB 是否健康，关键不是看它是否存在，而是看它是否“安静”：

• 开启 -Xlog:gc+allocation=debug，关注 Eden 分配失败率（allocation failure）
• 启用 -XX:+PrintTLAB，检查 refill 频次和平均浪费率（waste percent）
• 若 refill 过于频繁或 waste 长期 >5%，说明 TLAB 大小策略失衡，可能拖慢 Minor GC 触发节奏