tlab是jvm为每个线程在eden区私有分配的缓冲区，通过top/end指针实现无锁对象分配，仅tlab重填时需加锁，以空间换时间提升数十倍性能。
关闭 -XX:-ResizeTLAB 并不是“强行固化”TLAB大小的正确方式，恰恰相反——该JVM参数默认是开启的（即 -XX:+ResizeTLAB），它允许JVM在运行时动态调整每个线程的本地分配缓冲区（TLAB）大小。而 -XX:-ResizeTLAB 才是**禁用**这一自适应机制的开关。
真正用于“固化”TLAB大小的参数是：-XX:TLABSize=（单位为字节），配合 -XX:-ResizeTLAB 使用，才能达到预期效果。
为什么在压力测试中会出现“性能锯齿”？
TLAB 是每个线程私有的堆内存小块，用于快速分配对象，避免竞争 Eden 区的共享指针。JVM 默认启用自适应 TLAB（+ResizeTLAB），会根据线程的分配速率、晋升行为、GC日志等实时反馈，周期性地调整 TLAB 大小：
- 分配快 → 增大 TLAB → 减少同步分配次数 → 吞吐提升
- 分配慢或易填满 → 缩小 TLAB → 降低内存浪费与 GC 扫描开销
但在某些高并发、分配模式突变（如批量构造 DTO、突发日志对象）的压力场景下，这种自适应可能引发“震荡”：TLAB 频繁缩放 → 分配路径切换（TLAB内 vs 共享Eden）→ 内存访问局部性下降 → GC 暂停时间波动 → 表现为吞吐量/响应时间出现规律性锯齿（例如每10–30秒一次毛刺）。
如何用 -XX:-ResizeTLAB + TLABSize 稳定分配行为？
目标是绕过JVM的在线调优逻辑，让所有线程始终使用统一、预估合理的固定大小TLAB。操作分三步：
-
第一步：观测基线 —— 在开启
+ResizeTLAB（默认）下跑压测，用-Xlog:gc+tlab=debug或 JFR 记录 TLAB 统计，重点关注各线程平均 TLAB 使用率（tlab_used / tlab_size）和 refill 频次。理想值是 70%~90%，过高易导致频繁 refill，过低则浪费内存。 -
第二步：设定固定值 —— 取观测到的稳定线程 TLAB 平均大小（如 256KB），显式设置：
-XX:+UseTLAB -XX:-ResizeTLAB -XX:TLABSize=262144（256×1024） -
第三步：验证与微调 —— 再次压测，观察：
- TLAB refill 日志是否消失（仅初始化时有）
- Eden 区分配失败（
slow path allocation）是否显著减少 - GC pause 的标准差是否下降、吞吐曲线是否平滑
注意事项与常见误用
这个策略有效，但不普适，需警惕以下几点：
-
不要全局设过大：比如设
TLABSize=4m，会导致小对象线程大量内存闲置，尤其在轻量请求线程多的场景（如Web容器），反而推高堆占用、加剧GC压力。 -
注意平台差异：HotSpot 在 G1 和 ZGC 下对 TLAB 的管理逻辑不同；ZGC 中 TLAB 更轻量，
-ResizeTLAB影响较小；G1 则更敏感。 - 不能替代根本优化：若锯齿源于大量临时对象逃逸、字符串拼接未用 StringBuilder、或日志格式化未用占位符，固化 TLAB 只是掩盖症状，应优先修复代码分配模式。
