tlab的核心作用是让绝大多数对象分配彻底绕开竞争，即为每个线程在eden区分配专属私有缓冲区，使小对象分配仅需本地指针碰撞（bump-pointer）且无锁、无cas、无同步，耗时纳秒级；仅当tlab用尽、对象过大、显式关闭或栈上分配时才回落共享eden慢路径。
TLAB 的核心作用不是“缓解”竞争，而是让绝大多数对象分配操作彻底绕开竞争——它不靠更细的锁，而靠给每个线程发一块专属内存“自用”，把多线程抢同一块地，变成各干各的、互不打扰。
TLAB 怎么从根源上消除分配锁
没有 TLAB 时，所有线程都得争 Eden 区那个全局的分配指针（比如 top 指针），每次 new 都要 CAS 更新，失败就重试，高并发下大量自旋和缓存失效。启用 TLAB 后：
- 每个线程在 Eden 内拥有自己的一段连续内存（如起始 0x1000，末尾 0x1100）
- 分配小对象时只检查本地 top + 对象大小 ≤ end，成立就直接 bump 指针（如从 0x1050 → 0x1070）
- 整个过程纯寄存器操作，无锁、无 CAS、无同步，耗时在纳秒级
- 只有 TLAB 用尽时才需加锁申请新缓冲区，这个动作频率极低
哪些情况会重新掉回锁竞争路径
TLAB 只覆盖高频小对象场景，以下情况会绕过它，触发共享 Eden 分配（即走慢路径）：
- 对象大小超过当前 TLAB 剩余空间，且 refill 失败（例如 Eden 已碎片化或剩余不足）
- 对象本身较大（如大数组），超过 JVM 内部阈值（默认约 2KB～64KB，取决于版本和参数）
- 显式关闭：-XX:-UseTLAB（生产环境严禁）
- 逃逸分析成功 → 对象栈上分配，根本不上堆，TLAB 不参与
怎么确认 TLAB 正在有效工作
不能只看参数是否开启，默认开启不代表运行时生效。关键看 GC 日志：
- 启动加 -Xlog:gc+alloc=debug（JDK 10+）或 -XX:+PrintTLAB -XX:+PrintGCDetails（旧版）
- 日志中出现类似 TLAB: gc thread: 0x... desired_size: 1024KB actual_size: 987KB 表示正常工作
- 关注字段：slow_allocations（应 refill_waste（单次不宜超 50KB）、TLAB allocation failed（太多说明 TLAB 过小或 Eden 碎片高）
调优重点不在设大小，而在看行为反馈
JVM 默认开启 -XX:+ResizeTLAB，会根据线程分配速率动态调整 TLAB 大小。硬设 -XX:TLABSize 容易适得其反：
- 设太小 → refill 频繁 → slow_allocations 上升 → 实际同步开销反而增加
- 设太大 → 单个线程占满 Eden 连续空间 → 其他线程申请 TLAB 失败率升高
- 真正需要干预的信号是：refill_waste 长期 >10% Eden 容量 或 Eden 利用率低但 EU 增长不连续，此时可微调 -XX:TLABWasteTargetPercent（默认 1%）
