OpenJDK的TLAB为什么能加快对象分配-java教程-PHP中文网

tlab能绕过锁竞争，是因为它为每个线程在eden区划分私有缓冲区，小对象分配仅需本地指针碰撞（bump-pointer），无锁、无cas、无同步；仅tlab耗尽时 refill 才需一次cas更新全局指针。

openjdk的tlab为什么能加快对象分配

堆是所有线程共享的，直接在 Eden 区分配对象必须保证指针（eden_top）更新的原子性。HotSpot 默认用 CAS + 自旋重试实现，但高并发下大量线程争抢同一地址，失败率上升、延迟毛刺明显。

TLAB 的本质是把 Eden 切成若干份“线程私有小块”，每个线程只操作自己的 tlab_top，分配就是简单的指针碰撞（bump-the-pointer），完全不涉及任何同步原语。

TLAB 不是额外内存池，它始终从 Eden 中划出连续区域。它的存在反而让 Eden 的使用更“规整”：

OpenJDK 24

下载

小对象集中在各线程 TLAB 内部分配，天然形成局部性，减少跨 region 跳跃
TLAB 用尽后 refill 是批量申请（比如一次拿 256KB），比每次分配都零散请求更高效
如果 TLAB 太小（如 -XX:TLABSize=4k），refill 频繁 → 共享 Eden 区 CAS 次数飙升 → slow_allocations 上升，GC 日志里能看到 “TLAB waste” 却不触发回收
如果 TLAB 过大（如设为 Eden 的 50%），单个线程可能长期占着大块 Eden 空间却不填满，造成隐性浪费，提前触发 Young GC

TLAB 本身是 JVM 层机制，但它的实际效果高度依赖 GC 对 Eden 的管理能力：

G1 GC：每个线程在 Eden Region 中划分 TLAB，支持动态 resize 和精确 waste 统计；-XX:+PrintTLAB 可直接看到 refill 成功率和浪费率
Parallel GC：TLAB 利用率最高，refill 极其激进，但日志简略，需结合 -XX:+PrintGCDetails 推断是否因碎片导致 fallback
ZGC / Shenandoah：并发移动阶段 Eden 空间被 GC 线程隐式占用，TLAB refill 容易排队降级；此时 refill_waste 持续偏高，往往反映的是 GC 并发压力，而非 TLAB 配置不当

TLAB 只服务“小对象”的快速路径，以下情况会直接跳过 TLAB，走共享 Eden 或老年代：

对象大小超过 -XX:TLABWasteTargetPercent 控制的阈值（默认约 1% Eden），或大于当前 TLAB 剩余空间 → 直接在 Eden 分配（仍属新生代，但需 CAS）
对象太大，Eden 都放不下（比如 2MB 数组），JVM 会直接分配到老年代，绕过整个新生代流程
逃逸分析判定对象可栈上分配（-XX:+DoEscapeAnalysis 开启时），连堆都不进，自然不涉及 TLAB
显式禁用：-XX:-UseTLAB（极少数调试场景）

真正影响性能的，往往不是“TLAB 是否开启”，而是 Eden 是否足够连续、refill 是否频繁失败、以及对象大小分布是否匹配当前 TLAB 策略——这些细节藏在 GC 日志的 TLAB 行和 slow_allocations 计数里，而不是参数列表中。