并行流处理海量短期对象时对JVM GC冲击主要来自三方面：年轻代分配陡增、TLAB机制失效、GC频率与扫描压力同步抬升；本质是分配模式错配引发连锁反应，表现为Eden区快速填满、TLAB频繁重填充或浪费、Filler碎片增多及对象误晋升。
并行流处理海量短期对象时，对JVM垃圾回收的冲击主要来自三方面：年轻代分配陡增、TLAB机制失效、GC频率与扫描压力同步抬升。它不是“用得多就慢”，而是“分配模式错配”引发连锁反应。
短期对象爆发式分配，直接压满Eden区
并行流（如 list.parallelStream().map(...).collect(...)）会在线程池中多个线程并发执行，每个线程都可能在短时间内创建大量中间对象（如临时String、包装类、Lambda闭包捕获的局部变量、Stream内部的Spliterator节点等）。这些对象生命周期极短，但集中涌向Eden区，导致：
- Eden使用率（EU）快速冲高，频繁触发Minor GC
- 若对象尺寸偏大（如map中生成的byte[]、JSON解析结果），还会绕过TLAB，加剧共享Eden区CAS竞争
- jstat -gc 输出中，YGC次数激增 + EU/EC长期>85% 是典型信号
TLAB在并行流场景下大面积失效
并行流线程并非固定线程，ForkJoinPool.commonPool()中的工作线程是动态调度的，且每个线程的TLAB大小默认由JVM自适应调整（-XX:+UseTLAB + -XX:TLABSize）。但面对突发、不均的对象分配节奏：
- TLAB过小 → refill请求暴增（PrintTLAB日志中高频出现“refill requested”）
- TLAB过大 + 对象尺寸分布离散 → waste字段持续偏高（如单次refill前剩余120KB未用），说明空间浪费严重
- 更关键的是：一旦某个map操作产生一个超过当前TLAB剩余空间一半的对象（例如剩余1.6MB时new byte[900KB]），该对象立刻走共享Eden区，触发CAS抖动和Filler碎片
GC行为恶化：从延迟毛刺到扫描链表膨胀
短期对象虽“活不久”，但它们密集进入Eden后，并非安静等待回收——它们会显著拉长GC实际开销：
- 初始标记阶段需遍历所有Eden存活对象，对象数量翻倍 → STW时间延长
- 复制算法阶段（如Parallel Scavenge或G1 Young GC）需搬运更多存活对象到Survivor，带宽压力上升
- 大量Filler Object（由绕过TLAB的大对象触发）混入Eden，不参与业务但占用扫描链表长度，增加标记与清理耗时
- 若Survivor区无法容纳全部短期存活对象，会提前晋升至老年代，埋下Full GC隐患
可观测与调优切入点
不要只盯着GC日志里的“GC time”，要交叉验证：
- 加 -XX:+PrintTLAB -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -Xlog:gc+tlab=debug，观察各线程refill频次与waste值
- 用 jstat -gc
持续采样，重点关注 EC（Eden容量）、EU（已用）、YGC（次数）、YGCT（耗时） 的联动趋势 - 开启 -Xlog:gc+age=trace 查看对象年龄分布，确认是否有大量1~2岁对象被错误晋升
- 必要时限制并行度：System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "4")，比盲目扩容堆更有效
