TLAB溢出本质是对象卡在TLAB剩余空间临界点，既放不进TLAB又不够大入老年代，被迫退至Eden区同步分配，加剧Minor GC；需通过-XX:+PrintTLAB观察waste_percent>5%或slow_alloc频次突增来确认，并优先启用-XX:+ResizeTLAB动态调优而非硬设大小。

这个问题本质是TLAB（Thread Local Allocation Buffer）空间不足导致对象“溢出”到共享Eden区，进而加剧Minor GC频率。关键不在于对象“大”，而在于它卡在TLAB剩余空间临界点上——既放不进当前线程的TLAB，又不够大到直接进入老年代，只能退回到Eden区分配，加速Eden填满。

确认是否真是TLAB溢出问题

先看GC日志中是否有频繁的TLAB allocation failure或slow path allocation提示；再用JVM参数开启TLAB统计：
-XX:+PrintTLAB -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
观察输出中tlab_waste_percent是否长期高于5%～10%，或tlab_slow_alloc次数明显高于tlab_fast_alloc。

调高TLAB大小或启用自适应策略

TLAB默认大小由JVM自动估算，但对高并发、小批量中等对象场景常偏保守：

• 显式增大TLAB：加参数-XX:TLABSize=512k（根据线程数和对象平均体积试调，常见值256k～1M）
• 更推荐启用动态调整：-XX:+UseTLAB -XX:+ResizeTLAB，让JVM根据实际分配压力实时扩缩TLAB
• 若对象体积分布集中，可配合-XX:TLABWasteTargetPercent=2收紧浪费阈值，促使JVM更积极扩容TLAB

从代码侧减少临界尺寸对象的生成

这类对象往往出现在以下场景：

• 动态数组初始化：如new byte[8192]（8KB），恰好略超默认TLAB（通常4～64KB，取决于堆大小）
• JSON反序列化时未预估长度，生成中等size的ArrayList或HashMap
• 日志拼接中临时StringBuilder容量突增

建议做法：

• 对已知尺寸范围的对象，显式指定初始容量，例如new ArrayList(128)、new StringBuilder(256)
• 用对象池复用固定规格的缓冲区（如ByteBuffer.allocateDirect()替代反复new byte[]）
• 检查Protobuf/JSON库配置，启用buffer复用或预设schema size hint

补充：避免误判为其他问题

TLAB溢出常被误认为是内存泄漏或堆太小。注意区分：

• 如果GC后Eden区几乎清空、老年代增长缓慢，且Minor GC间隔短但单次耗时低 → 倾向TLAB问题
• 如果Full GC同步增多、老年代持续上涨 → 应优先排查内存泄漏或大对象直接入老年代
• 单纯加-Xmx可能反而降低TLAB占比（JVM按比例分配），未必治本