tlab核心作用是让绝大多数小对象分配彻底绕开竞争，即为每个线程在eden区分配专属私有缓冲区，使分配仅需本地指针碰撞、无锁无cas；大数组则绕过tlab直入eden主空间，高并发下易触发allocation failure并导致晋升失控与老年代膨胀。

高并发下大量短命大数组对象会直接击穿分代回收的设计前提，造成年轻代快速淤塞、晋升失控、老年代被动膨胀——这不是GC调优能掩盖的问题，而是内存行为与JVM机制的硬冲突。

大数组绕过TLAB，直冲Eden区头部

普通小对象默认走线程本地分配缓冲（TLAB），分配快且线程间无竞争。但大数组（如 byte[8192] 以上）通常超过TLAB阈值，JVM会跳过TLAB，直接在Eden区主空间分配。高并发时多个线程同时向Eden头部写入大块连续内存，极易触发 Allocation Failure，导致Minor GC频次陡增。更关键的是，这些大数组几乎不存活到下一次GC，但每次分配都消耗大量Eden空间，使Eden“虚高”填满。

Survivor区迅速失效，晋升阈值被动态压低

大数组生命周期极短，基本不会进入Survivor区；即便有少量幸存，也因体积过大无法容纳于默认Survivor空间（通常仅占新生代10%）。GC日志中频繁出现 Desired survivor size … new threshold = 1，说明JVM已将晋升年龄阈值降至最低——所有跨过第一次GC的对象，无论是否真该活久一点，全部直接晋升至老年代。

老年代承接无效压力，诱发隐性Full GC风险

大量本该在新生代就消亡的大数组，因Survivor溢出而批量晋升，快速堆高老年代使用率。它们虽不长期驻留，但因尺寸大、分布散，G1或CMS难以高效回收；若老年代占用率持续逼近阈值（如 G1 的 InitiatingHeapOccupancyPercent），就会提前触发并发标记，甚至在并发失败后退化为Stop-The-World式Full GC。此时停顿时间不再由对象数量决定，而由这些大数组的总跨度和跨代引用关系主导。

缓解的关键不在“调大堆”，而在“截断分配源头”

• 用池化替代新建：对固定规格大数组（如4KB/8KB缓冲区），优先使用 ThreadLocal 或对象池（如 Apache Commons Pool）复用
• 改用堆外内存：对纯计算/IO缓冲场景，用 ByteBuffer.allocateDirect() 将压力移出堆，避免干扰分代节奏
• 拆分粒度，降低单次分配量：例如将一个 byte[64*1024] 拆为8个 byte[8*1024]，提高TLAB命中率，减少Eden头部争抢
• 启用JVM参数显式干预：如 -XX:+UseTLAB -XX:TLABSize=64k 提高大数组进入TLAB的可能性；-XX:MaxTenuringThreshold=1 配合业务逻辑，主动控制晋升节奏