TLAB溢出本质是对象分配撞上边界对齐“硬卡点”，非GC问题；需通过微调TLAB大小避开页对齐倍数、降低TLABWasteIncrement、控制对象尺寸可预测性来绕开临界态，而非简单调大TLAB或改GC算法。
这个问题本质是对象分配撞上了TLAB边界对齐的“硬卡点”，不是GC策略问题，而是内存布局与硬件页对齐规则在JVM层的隐性冲突。关键不在调大TLAB或改GC算法，而在于让对象分配绕开那个“刚好差一点就进得去、但因对齐被迫溢出”的临界态。
识别是否真由页对齐触发TLAB溢出
先确认现象是否匹配：Minor GC频率异常升高（比如每100ms一次），但Eden区平均使用率仅40%~60%，GC后存活对象极少，且GC日志中频繁出现 TLAB refill 或 slow path allocation 字样。用 -XX:+PrintTLAB 开启TLAB日志，观察每条记录里的 waste 值——若大量线程的 waste 接近甚至等于 refill_waste_limit（默认为256字节），且 top 指针离 end 仅差几十字节，基本可锁定是页对齐导致的“伪满”。
核心调优动作：微调TLAB大小与对齐策略
TLAB默认按平台内存页大小（通常是4KB）对齐，但对象分配请求会向上取整到8字节（64位JVM）或4字节（32位）。当一个对象实际需1020字节，加上对齐填充后变成1024字节，而当前TLAB剩余空间只剩1023字节，就会强制走慢路径并触发TLAB refill——哪怕只差1字节。
- 用
-XX:TLABSize=XXk手动指定TLAB大小，避开常见页对齐倍数（如不设4096，改设4080或4104），让剩余空间更“耐凑” - 降低浪费阈值：
-XX:TLABWasteIncrement=128（默认256），让TLAB更早主动 refill，避免卡在临界点 - 关闭强制页对齐（慎用）：
-XX:-UseTLABRefillWasteLimit，让TLAB refill不再受 refil_waste_limit 约束，但需配合更小的TLABSize防止内存碎片
代码侧配合：控制对象尺寸的“可预测性”
高频分配的小对象（如DTO、临时List、短生命周期Map.Entry）最容易被对齐规则“卡住”。与其被动适配，不如主动归一化：
- 对固定结构对象，用
@Contended或字段重排减少padding（需开启-XX:-RestrictContended） - 避免混合大小字段声明（如 long + byte + int），会导致JVM插入大量填充字节
- 对纯数据容器，优先用
ByteBuffer.allocateDirect()或对象池复用，跳过堆分配环节
验证是否生效
调优后重点看三项指标是否同步改善：
- TLAB refill 次数下降 ≥ 60%
- Minor GC pause time 波动范围收窄（标准差降低50%以上）
-
jstat -gc中EC（Eden容量）与EU（Eden使用量）比值稳定在0.7~0.8，不再频繁触顶
