阻塞队列本身不直接导致OOM，但作为压力放大器，当任务提交速率持续大于消费速率且队列无界（如默认Integer.MAX_VALUE的LinkedBlockingQueue）时，大量任务对象在堆中堆积，最终触发OutOfMemoryError: Java heap space。
阻塞队列本身不会直接导致 JVM 堆内存溢出，但它是一个关键的“压力放大器”——当任务持续提交、消费速度跟不上、且队列有界时，任务对象会在堆中不断堆积，最终耗尽堆空间。预防的核心不是调大队列容量，而是控制“任务生命周期 + 队列行为 + 拒绝策略”的协同机制。
明确阻塞队列与内存溢出的传导路径
典型链路是：线程池使用有界阻塞队列（如 ArrayBlockingQueue）→ 任务提交速率 > 消费处理速率 → 队列逐渐填满 → 新任务被拒绝或阻塞 → 若拒绝策略为 CallerRunsPolicy 或未设限的 LinkedBlockingQueue（默认 Integer.MAX_VALUE）→ 任务对象持续创建并入队 → 堆中积累大量待执行 Runnable/Callable 实例 → 触发 OutOfMemoryError: Java heap space。
注意：无界队列（如默认容量的 LinkedBlockingQueue）风险更高——它看似“不拒绝”，实则把背压转移到堆内存，是隐蔽的 OOM 温床。
实战中必须检查的三项配置
在初始化线程池时，这三项必须显式声明，不能依赖默认值：
- 队列类型与容量必须有界：优先选 ArrayBlockingQueue 并指定合理容量（例如 1024 或 2048），避免使用无参 LinkedBlockingQueue；容量值需结合单任务对象大小、预期峰值并发、可用堆内存估算（例如：若单任务对象约 1KB，堆预留 100MB 可用空间，则队列上限建议 ≤ 100_000）
- 拒绝策略必须可监控、可降级：禁用默认的 AbortPolicy（仅抛异常）；推荐使用自定义策略，例如记录日志 + 上报指标 + 触发熔断（如返回失败响应或降级逻辑），而非简单丢弃或交由调用线程执行（CallerRunsPolicy 在高负载下会拖垮请求线程，加剧延迟和内存压力）
- 核心线程数与最大线程数需匹配业务特征：若任务 I/O 密集（如 DB 查询、HTTP 调用），可适当提高 maxPoolSize 并配合较短的 keepAliveTime，让线程在空闲时及时回收，避免长期持有大对象引用（如 Connection、Buffer）造成间接内存泄漏
通过 JVM 参数与工具提前暴露问题
光靠代码配置不够，要让系统“自己说话”：
- 启动时添加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps，确保 OOM 时自动生成堆转储文件
- 开启 GC 日志：-Xlog:gc*:file=/logs/gc.log:time,tags,level（JDK 11+），关注是否出现频繁 G1 Evacuation Pause 或长时间 Full GC，这是任务积压已影响内存回收的信号
- 运行时用 jstat -gc
查看 S0C/S1C、EC、OC 使用率，若老年代（OC）持续高于 70% 且不下降，说明队列中长期存活的任务对象已进入老年代，回收困难 - 用 MAT 分析 dump 文件时，重点筛选 java.util.concurrent.ArrayBlockingQueue$Node 或你自定义的 Task 类实例，按“Retained Heap”排序，确认是否为最大内存占用者
代码层防御：任务对象轻量化与及时清理
即使队列受控，每个任务仍可能携带大对象（如原始 byte[]、JSON 字符串、未关闭的流）。预防要点：
- 任务类避免持有外部大对象引用；必要时用 WeakReference 包装非关键缓存
- 在任务 run() / call() 执行末尾，显式清空内部临时集合、置 null 大字段（尤其在循环处理场景中）
- 禁止在任务中创建未关闭的 DirectByteBuffer（属于直接内存，不受堆参数限制，但会挤占物理内存，间接导致堆 GC 压力上升）
- 对批量任务做分片（chunking）：例如一次处理 100 条 DB 记录，而不是把 10 万条全 load 到内存再提交到队列
