TLAB卡点是指对象大小略超当前TLAB剩余空间，导致频繁refill或退化至Eden慢分配，加剧Minor GC。可通过日志识别、调优TLAB策略、控制对象尺寸及夯实Eden空间来解决。
这个问题核心在于对象“卡点”——不是太大进不了TLAB，也不是小到能被轻松容纳，而是刚好比当前TLAB剩余空间大一点点，导致每次分配都触发Refill或退化到Eden区慢路径，进而加速Eden填满、推高Minor GC频率。
看准信号：确认真是TLAB卡点溢出
- GC日志中Minor GC后Eden几乎清空（如
PSYoungGen: 1280509K->5120K），Survivor晋升量长期低于几KB，老年代无增长 - 开启
-XX:+PrintTLAB后，某线程每秒 refills 超2–3次，且 waste 值忽高忽低（例如从200字节跳到1800字节） - 日志反复出现
slow path allocation或humongous allocation，说明对象已绕过TLAB直冲Eden共享区，触发CAS竞争
调TLAB策略：让伸缩节奏匹配真实分配
- 确保
-XX:+ResizeTLAB启用（JDK8+默认true），JVM会根据线程近期分配速率自动扩缩TLAB - 收紧浪费容忍度：
-XX:TLABWasteTargetPercent=1，把目标平均浪费压到1%以内，促使JVM更积极扩容 - 若线程数稳定、流量特征清晰（如网关固定每线程处理300KB/秒），可关闭自适应：
-XX:-ResizeTLAB -XX:TLABSize=384k，避免resize抖动
控对象尺寸：从代码侧避开临界点
- JSON反序列化生成的ArrayList或HashMap，未预估容量，导致底层数组扩容后恰好略超TLAB剩余
- 日志拼接用StringBuilder临时扩容，如从256字节突增到8192字节
- 动态
new byte[n]，n接近但略大于当前TLAB剩余（如剩余80KB，分配81KB缓冲） - 显式指定初始容量：
new ArrayList(128)、new StringBuilder(512) - 对固定规格缓冲区（如网络包、解码buffer），用
ThreadLocal池化复用，避免反复分配 - 检查Protobuf/JSON库是否支持buffer复用或schema size hint，减少运行时临时扩容
夯实Eden底座：给TLAB足够伸缩空间
- 年轻代设为堆的1/3～1/2（如
-Xms4g -Xmx4g -Xmn2g），避免老年代挤压 - 保持
-XX:SurvivorRatio=8（即Eden占年轻代80%），不要盲目调小该值——设成2反而压缩Eden - TLAB是从Eden划分出来的，Eden太小会直接限制TLAB上限，间接加剧卡点现象
不复杂但容易忽略
