本质是分发逻辑中频繁创建短命对象引发GC压力，需切断CyclicBarrier与对象分配绑定、合并分发单元粒度、显式调控JVM内存参数以抑制碎片抖动。
这个问题本质是对象生命周期与并发控制结构耦合不当引发的 GC 压力，核心不在 CyclicBarrier 本身（它不存对象），而在于围绕它构建的“分发逻辑”中频繁创建短命对象（如 Runnable、Lambda、临时容器、图片元数据包装类等），导致年轻代 Eden 区快速填满，Minor GC 频发；同时因对象分配模式不连续或复用缺失，加剧内存碎片化，进一步抬高 GC 触发频率。
下面从三个关键角度给出可落地的改进方向：
一、切断 CyclicBarrier 与高频对象分配的绑定
CyclicBarrier 是同步协调工具，不该承载数据或任务载体。常见错误是每次 await() 前都 new 一个 Runnable 或封装类来“塞进线程池”，这会直接向年轻代注入大量瞬时对象。
- ✅ 正确做法：预创建固定数量的、可复用的任务执行器（如静态内部类 + resettable 状态）
- ✅ 把图片分发逻辑拆成“准备阶段”和“执行阶段”，前者只做轻量引用传递（如
int[] imageIds、AtomicIntegerArray offsets），后者在 worker 线程内复用已有对象处理 - ❌ 避免写法：
// 错误：每次 barrier await 都 new 新对象 executor.submit(() -> { ImageTask task = new ImageTask(imgData, metadata); // 每次都 new！ distribute(task); });
二、控制分发单元粒度，减少对象生成频次
“队列过长”往往源于把一张图拆成几十个 tiny chunk 并逐个提交，每个 chunk 封装为独立对象。这不是并发优化，是 GC 恶化器。
- 合理合并：按设备能力/线程数预估单次处理的像素块大小（如 512×512），让每个任务处理一块完整区域，而非单行/单像素
- 复用缓冲区：用
ThreadLocal<ByteBuffer>或对象池管理byte[]缓冲，避免每次 decode/copy 都 new 数组 - 元数据扁平化：不用
Map<String, Object>存图片参数，改用int flags+long timestamp+short width/height等字段直写，消除包装对象
三、显式引导 GC 行为，抑制碎片抖动
年轻代碎片抖动常因 Survivor 区空间不足、对象被迫提前晋升至老年代，触发连锁 Full GC。需主动干预：
- 设置
-XX:SurvivorRatio=8（Eden : 1 Survivor = 8:1），并配合-XX:+UseAdaptiveSizePolicy让 JVM 自适应调整 - 若使用 G1，开启
-XX:+G1UseAdaptiveIHOP，并调低初始老年代占用阈值（-XX:InitiatingOccupancyPercent=35），避免大对象静默晋升 - 关键路径上禁用
System.gc()和显式Runtime.getRuntime().gc()，防止干扰 JVM 的回收节奏
不复杂但容易忽略。
