必须显式指定LinkedBlockingQueue容量，禁用无参构造；需结合线程池、业务水位与资源闭环设计，配套拒绝策略与监控告警。
LinkedBlockingQueue 容量上限不能留空或依赖默认值，必须显式指定一个合理整数。关键不是“设多大”，而是让容量与线程池行为、业务水位和系统资源形成闭环。
必须显式设置容量值
避免使用无参构造 new LinkedBlockingQueue()——它等价于 new LinkedBlockingQueue(Integer.MAX_VALUE)，属于“伪无界”：节点持续堆上分配，GC 压力随积压线性上升，极易引发 OOM。生产环境一律写明数字：
-
new LinkedBlockingQueue(200)—— 适合库存预扣类短任务 -
new LinkedBlockingQueue(500)—— HTTP 异步日志常见取值 -
new LinkedBlockingQueue(100)—— 轻量通知、状态变更事件推荐起点
按业务负载反推容量
脱离实际流量拍脑袋定值风险极高。建议从两个角度估算：
- 按吞吐差值估算：若消费者（4 线程）理论吞吐 80 任务/秒，而生产者峰值达 120/秒，则每秒净积压 40 条 → 若允许堆积不超过 10 秒，容量 ≈ 400
-
按排队时长倒推：公式为
容量 ≈ (maxPoolSize × 平均任务耗时ms × 允许最大排队秒数) / 1000。例如 max=8、耗时 100ms、容忍排队 2 秒 → 容量 ≈ 1.6，取 2～5 即可；再大就是掩盖性能瓶颈
绑定拒绝策略，让溢出可感知
有界队列 + 拒绝策略才是完整边界控制。光设容量不配策略，溢出时可能静默丢任务或阻塞上游：
立即学习“Java免费学习笔记（深入）”；
-
AbortPolicy（推荐默认）：抛
RejectedExecutionException，监控易捕获，适合强一致性链路 - DiscardOldestPolicy：丢最老任务，适合行情推送、实时状态更新等时效敏感场景
- 慎用 CallerRunsPolicy：由调用线程执行，可能拖垮 HTTP 线程池，放大雪崩
- 自定义策略更稳妥：记录被拒任务 ID、打点统计、联动降级开关（如关闭非核心异步写）
配套监控，容量才真正生效
只设容量不看指标，等于没设。必须持续采集并告警：
-
queue.size()：每 10 秒采样一次，超容量 80% 立即告警 - 配合 GC 时间与 Full GC 频次，判断是否已出现内存压力传导
- 结合线程池活跃线程数、队列等待数、拒绝数，做根因定位
