无界队列导致对象堆积、老年代快速填满并触发频繁full gc；应改用有界队列+拒绝策略、控制图片对象生命周期、启用g1 gc并调优参数。
图片动态分发逻辑中使用无界队列（如 LinkedBlockingQueue 且未设容量上限），极易造成对象长期堆积、内存持续增长，最终迫使老年代快速填满，触发频繁 Full GC。这不是参数调优能绕开的问题，而是架构设计层面的隐患。核心思路是：**让队列有界、让任务可拒绝、让生命周期可控**。
明确无界队列为何直接推高 Full GC 风险
无界队列本质是“来者不拒”的缓冲区。在图片分发场景中，下游处理（如压缩、水印、CDN上传）一旦变慢或偶发阻塞，上游请求仍源源不断地入队——这些待处理的图片 Buffer、元数据对象、回调闭包等，全部滞留在堆中。它们多数存活时间远超新生代阈值，很快晋升至老年代。当老年代空间被缓慢但坚定地占满，JVM 就只能靠 Full GC 来挣扎回收，而每次 Full GC 都伴随秒级 STW，用户看到的就是图片加载卡顿、接口超时、监控毛刺密集出现。
用有界队列 + 拒绝策略替代无界队列
这是最直接有效的切断手段：
- 将
new LinkedBlockingQueue()替换为new LinkedBlockingQueue<task>(maxCapacity)</task>，例如设为 1000～5000（根据单任务内存占用和峰值并发估算） - 配套设置拒绝策略，避免线程池盲目扩容掩盖问题：
new ThreadPoolExecutor(core, max, keepAlive, unit, queue, handler)
推荐使用AbortPolicy（抛异常，促上游降级）或CallerRunsPolicy（由提交线程自己执行，自然限流） - 配合监控：对队列 size、拒绝次数、线程池活跃线程数做 Prometheus 指标埋点，一旦接近阈值立即告警
控制图片对象生命周期，减少老年代压力
图片处理过程中的临时对象（如 BufferedImage、byte[]、ByteArrayOutputStream）体积大、存活久，极易成为晋升主力：
- 避免在队列中缓存原始大图字节数组；改用轻量级任务对象（含 URL、尺寸、格式等元信息），真正加载和解码推迟到消费者线程
- 处理完立即显式置空大对象引用（如
img = null），尤其在 try-finally 或作用域末尾，辅助 GC 判定可达性 - 对高频复用的小图操作（如统一缩略图尺寸），考虑使用对象池（如 Apache Commons Pool）复用 BufferedImage 实例，而非反复 new
调整 GC 策略与关键参数，匹配业务节奏
即使做了队列治理，仍需适配 JVM 层面以降低风险：
- 弃用默认 Parallel GC，改用 G1（
-XX:+UseG1GC）：它按 Region 分块回收，能更早识别并清理老年代中已失效的大图对象，显著减少 Full GC 触发概率 - 限制最大停顿目标：
-XX:MaxGCPauseMillis=200，让 G1 主动控制回收节奏 - 预留老年代缓冲空间：
-XX:G1HeapRegionSize=1M（若图片多为几百 KB 级别），避免单个大图跨 Region 导致碎片化 - 关闭显式 GC：
-XX:+DisableExplicitGC，防止日志打印、监控探针等代码误调System.gc()
