tlab溢出核心是对象“卡点”分配：略超tlab剩余空间，被迫退至eden区导致minor gc频发；需通过-xx:+printtlab观察tlab_waste_percent>5%～10%或tlab_slow_alloc突增来确认，并优先启用-xx:+resizetlab动态调优而非硬设大小。
这个问题核心在于对象“卡点”——不是太大，也不是太小，而是刚好比当前线程TLAB剩余空间大一点，放不进TLAB，又不够大到直接进老年代，只能退到共享Eden区分配，导致Eden快速填满、Minor GC频发。
确认是不是TLAB溢出问题
别急着调参数，先验证。加JVM参数启动应用：
- -XX:+PrintTLAB -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
观察日志中两个关键指标：
- tlab_waste_percent 长期高于5%～10%，说明TLAB常被提前放弃
- tlab_slow_alloc 次数明显多于 tlab_fast_alloc，代表大量对象走慢路径分配
如果GC日志里频繁出现 TLAB allocation failure 或 slow path allocation，基本可以锁定。
优先启用动态TLAB调优
硬设 -XX:TLABSize 容易在多线程负载波动时失效。更稳妥的做法是让JVM自己适应：
- 开启自适应： -XX:+UseTLAB -XX:+ResizeTLAB
- 收紧浪费容忍： -XX:TLABWasteTargetPercent=2（默认是1%，设为2可促使JVM更早扩容）
ResizeTLAB会在运行时根据各线程分配压力自动扩缩TLAB大小，对高并发、对象尺寸集中的场景效果明显。
从代码侧避开临界尺寸对象
这类“卡点对象”常见于：
- new byte[8192]、new ArrayList()无参构造（默认10）、StringBuilder无参（默认16）
- JSON反序列化生成的中等容量集合，或日志拼接时临时扩容的缓冲区
建议做法：
- 显式指定初始容量：如
new ArrayList(128)、new StringBuilder(512) - 复用固定规格缓冲区：用
ByteBuffer.allocateDirect()替代反复 new byte[] - 检查Protobuf/JSON库是否支持 buffer 复用或 size hint（如 Jackson 的
DeserializationConfig）
注意别误判成其他问题
TLAB溢出的表现有特征：
- Minor GC 频繁但单次耗时短，Eden区每次GC后几乎清空
- 老年代增长缓慢，Full GC 很少或没有
- 堆总使用率不高，却仍高频 Minor GC
如果老年代持续上涨或 Full GC 增多，应排查内存泄漏或大对象直入老年代，而不是调TLAB。
