LinkedBlockingQueue 默认容量为 Integer.MAX_VALUE 是为避免丢任务，但易致 OOM；应显式指定容量或封装代理队列实现背压，配合监控与合理拒绝策略。
为什么 LinkedBlockingQueue 的默认容量是 Integer.MAX_VALUE
Java 线程池用 newFixedThreadPool 或 newSingleThreadExecutor 时，底层队列默认是 LinkedBlockingQueue，且构造时不传参 → 容量变成 Integer.MAX_VALUE。这不是设计疏忽，而是为了“不丢任务”——但代价是内存无限吃涨，尤其在下游响应变慢、生产者持续提交时，队列会堆积成 OOM 的导火索。
常见错误现象：java.lang.OutOfMemoryError: Java heap space，堆 dump 显示大量 Runnable 或业务 FutureTask 实例滞留在 LinkedBlockingQueue 内部的 Node 链表中。
- 别指望 GC 能及时回收：只要队列引用还活着，这些任务对象就不可达释放
- 不是所有场景都适合换
ArrayBlockingQueue：它固定大小 + 不可扩容，offer 失败会直接丢任务，而你可能需要的是“背压反馈”，不是静默失败 -
SynchronousQueue更激进：不存任务，全靠线程交接，适用于纯 CPU 密集、无排队需求的场景，和“动态调队列长度”的目标不匹配
怎么安全地让队列长度可调：绕过构造器限制
LinkedBlockingQueue 的容量在构造后不可变，但你可以用 ThreadPoolExecutor 的完整构造函数，把自定义队列传进去——关键在于：这个队列得是你自己可控的实例，而不是靠工厂方法生成的黑盒。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 显式 new 一个带容量的
LinkedBlockingQueue<Runnable>，比如new LinkedBlockingQueue<Runnable>(1000) - 用
new ThreadPoolExecutor(..., queue, ...)构造线程池，别用Executors工厂类 - 如果真需要“动态调整”，不能改队列容量，但可以封装一层代理队列，在
offer()里做限流判断，比如结合AtomicInteger记录当前 size，超阈值时抛RejectedExecutionException或降级写入磁盘 - 别试图反射修改
LinkedBlockingQueue.capacity：字段是 final，且 JDK 9+ 模块系统会阻止非法访问
拒绝策略选哪个才真正起作用
队列满了之后，新任务交给 RejectedExecutionHandler。很多人设了 AbortPolicy 却没观察日志，结果误以为“队列没满”，其实是任务被静默拒绝了。
使用场景决定策略选择：
-
AbortPolicy（默认）：抛RejectedExecutionException，适合强一致要求、必须立刻感知失败的场景 -
CallerRunsPolicy：让提交线程自己执行任务，能自然减缓生产速度，但要注意调用线程是否允许长时间阻塞 - 自定义 handler 中记录 metric 或发告警，比单纯打印 stack trace 更有用；避免在 handler 里做复杂 I/O 或锁操作，否则会拖垮整个提交流程
- 别用
DiscardPolicy或DiscardOldestPolicy做“兜底”：它们不抛异常也不通知，问题会延迟暴露
监控队列水位比调参数更重要
硬编码队列长度（比如 1000）只是权宜之计。真实系统里，流量峰谷波动大，固定值要么太小导致频繁拒绝，要么太大掩盖内存隐患。
你应该做的：
- 暴露
queue.size()和queue.remainingCapacity()到 metrics（如 Micrometer 的Gauge），配合告警阈值（比如 >80%） - 注意
size()是非原子快照，高并发下可能不准，但用于趋势监控完全够用 - 不要每秒轮询一次
size()打日志：开销不小，且日志爆炸；改用采样或聚合上报 - 如果发现水位长期 >50%，优先查下游服务延时、数据库慢查询、远程调用超时设置，而不是急着调大队列
动态调整的本质不是“让队列变长”，而是让系统在过载时有明确的反馈路径和应对节奏。队列只是缓冲区，不是保险丝——保险丝该熔断时，就得响。
