TLAB 是什么，为什么每个线程要自己分一块小内存
TLAB（Thread Local Allocation Buffer）是 JVM 在堆内存中为每个线程单独划出的一小块连续空间，专供该线程快速分配对象。它不是独立于堆之外的区域，而是 Eden 区内的“私有子区”。没有 TLAB 时，所有线程都要竞争 Eden 的公共指针（如 top），频繁加锁或 CAS，成为性能瓶颈；启用后，线程直接在自己的缓冲区里挪动本地指针，几乎无竞争。
常见错误现象：GC logs 里看到大量 TLAB waste 或 TLAB refill 频繁发生，说明大小配置不合理，不是太小（反复 refill 消耗 CPU），就是太大（浪费 Eden 空间、加剧 GC 压力）。
- 默认开启（HotSpot JDK8+），无需手动打开，但可通过
-XX:+UseTLAB显式确认 - TLAB 大小由 JVM 动态估算：基于线程分配速率、Eden 总大小、历史 refill 频率等，不是固定值
- 大对象（超过某个阈值）直接绕过 TLAB，在 Eden 公共区分配，这个阈值由
-XX:TLABWasteTargetPercent和内部算法共同决定
怎么查当前 TLAB 实际行为，而不是只看参数
光看 -XX:TLABSize 或 -XX:TLABWasteLimit 没用——JVM 很少按你写的静态值来分配。真实行为得靠日志和运行时指标验证。
使用场景：压测中发现 minor GC 频次异常升高，怀疑是 TLAB 配置拖累；或者想确认某类对象是否真的进了 TLAB。
立即学习“Java免费学习笔记（深入）”；
- 加 JVM 参数
-XX:+PrintTLAB，启动时会打印每轮 TLAB 分配/浪费/重填详情（注意：仅限 debug 版本 JVM，生产慎用） - 更通用的办法是开启 GC 日志：
-Xlog:gc+tlab=debug（JDK10+）或-XX:+PrintGCDetails（旧版），观察每次 GC 后的TLAB: gc thread: ... used: ... waste: ...行 -
jstat -gc <pid></pid>中的EU（Eden 使用量）和 GC 后突降幅度，结合 TLAB 日志，能反推单次平均 TLAB 占用
TLAB 大小调优的关键判断点
TLAB 不是越大越好，也不是越小越省。核心矛盾在于：增大可降低 refill 频率，但会提高对象晋升概率（因为 TLAB 满了但对象还活着，只能 copy 到 Survivor）；减小则增加同步开销，尤其在高并发短生命周期对象场景下明显。
性能影响明显的情况：大量小对象（如循环内 new Integer、StringBuilder）+ 高线程数（>50）+ Eden 不够大（-Xmn 偏小）。
- 如果日志中
waste占 TLAB 总大小比例长期 > 10%，说明当前 TLAB 过大或对象分配不均，可尝试降低-XX:TLABWasteTargetPercent（默认 1%） - 如果
refill次数远高于 GC 次数（比如 10:1），说明 TLAB 太小，可适当增大-XX:TLABSize（需配合-XX:+ResizeTLAB才生效） - 禁用 TLAB（
-XX:-UseTLAB）仅用于极端调试，会导致几乎所有对象分配走慢路径，吞吐暴跌，别在线上试
TLAB 和逃逸分析、栈上分配的关系容易被混淆
TLAB 解决的是“堆上分配的并发问题”，而逃逸分析（Escape Analysis）决定“这个对象能不能不进堆”。两者完全正交，但常被一起讨论，因为都影响对象分配路径。
容易踩的坑：以为开了 -XX:+DoEscapeAnalysis 就不需要关注 TLAB；实际上，未逃逸对象若仍被分配到堆（比如方法内对象被返回、或逃逸分析失败），还是会走 TLAB 路径。
- 栈上分配（Scalar Replacement）成功时，对象根本不会出现在堆或 TLAB 里，自然不涉及 TLAB 调优
- 但栈上分配成功率受方法内联深度、字段访问复杂度限制，很多看似简单的对象仍会落入 TLAB
- 可通过
-XX:+PrintEscapeAnalysis查看哪些对象被判定为未逃逸，再比对 GC 日志里的实际分配位置
TLAB 的边界其实很薄——它只管“怎么快”，不管“该不该分”。真正影响要不要分堆的，是逃逸分析；影响分得快不快的，才是 TLAB。这两层决策在 JIT 编译时就已分离，运行时互不感知。
