如何利用TLAB线程本地分配缓存解决堆内存变量竞争难点

TLAB的核心作用，不是“缓解”竞争，而是让绝大多数对象分配操作彻底绕开竞争——它不靠更细的锁，而靠给每个线程发一块专属内存“自用”，把多线程抢同一块地，变成各干各的、互不打扰。

其实，TLAB的核心作用不是“缓解”竞争，而是让绝大多数对象分配操作彻底绕开竞争——它不靠更细的锁，而靠给每个线程发一块专属内存“自用”，把多线程抢同一块地，变成各干各的、互不打扰。你猜怎么着？这种设计思路，就是直接釜底抽薪，与其让所有人挤一个入口，不如每人发一块自留地，各玩各的，互不干扰。

TLAB 怎么从根源上消除分配锁

没有TLAB的时候，所有线程都得挤在Eden区那个全局分配指针前，每次new都是一次CAS操作，失败就重试，高并发下自旋和缓存失效是家常便饭。启用TLAB之后，情况就完全不同了：每个线程在Eden区都有一块专属的连续内存，比如从0x1000到0x1100；分配小对象时，只需要检查本地top指针加上对象大小是否小于等于end，成立就直接把指针往上挪，比如从0x1050到0x1070；整个过程就是寄存器级别的操作，无锁、无CAS、无同步，耗时在纳秒级；只有TLAB用尽的时候，才需要加锁申请新的缓冲区，而这个动作发生的频率极低。

哪些情况会重新掉回锁竞争路径

TLAB并不是万能的，它只覆盖高频小对象场景。以下几种情况会绕过它，重新回到共享Eden分配的慢路径：对象大小超过当前TLAB剩余空间，而且refill也失败了，比如说Eden区已经碎片化或者剩余空间不足；对象本身比较大，比如大数组，超过了JVM内部阈值，默认在2KB到64KB之间，具体取决于版本和参数；显式关闭TLAB，比如设置了-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”这样的信息，就说明TLAB正在正常工作。重点关注几个字段：slow_allocations，应该小于总分配的5%；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%。