线程池任务队列溢出需有意识控制后果而非单纯避免，关键在于匹配业务预期选择队列类型（ArrayBlockingQueue可控、LinkedBlockingQueue慎用、SynchronousQueue适配高并发）、拒绝策略（CallerRunsPolicy限流、DiscardOldestPolicy丢旧、自定义落库保关键）及监控闭环，并依CPU/I/O密集型特征差异化配置。
线程池任务队列溢出不是“要不要处理”的问题，而是“如何有意识地控制后果”的问题。关键不在避免溢出本身，而在于让溢出行为符合业务预期——该丢弃时安静丢弃，该缓冲时可靠落盘，该降级时不影响主链路。
明确队列类型与溢出触发条件
溢出只在特定组合下发生：队列已满 + 线程数已达 maximumPoolSize。因此策略设计必须从队列选型开始：
- ArrayBlockingQueue（有界）：最可控。容量设为业务可容忍的最大积压量（如 200～1000），溢出即触发拒绝策略，适合支付、订单等强一致性场景。
- LinkedBlockingQueue（默认无界）：表面“不会溢出”，实则把风险转嫁给堆内存，极易引发 OOM。仅建议用于低吞吐、任务轻量且生命周期极短的后台服务，并务必显式指定容量（如 new LinkedBlockingQueue(500)）。
- SynchronousQueue（同步移交）：不存储任务，提交即需线程立即接手。此时“溢出”本质是线程创建失败，适用于高并发短任务（如 API 网关），但必须确保 maximumPoolSize 足够且线程创建开销可接受。
拒绝策略要匹配业务语义
默认的 AbortPolicy（抛异常）只适合调试或强校验场景；生产环境需按业务影响分级选择：
- CallerRunsPolicy：调用方线程执行任务。天然限流，适合异步日志、通知类任务，能防止雪崩但可能拖慢上游响应。
- DiscardOldestPolicy：丢弃队列头任务，再尝试提交新任务。适合时效性强的缓存刷新、状态同步等场景，旧任务价值低于新任务。
- 自定义落库/发MQ策略：将被拒任务持久化到数据库或消息队列，后续补偿执行。适用于订单创建、积分发放等不可丢失的关键操作。
监控与动态反馈闭环
策略生效的前提是能及时感知溢出。仅靠拒绝异常日志远远不够：
立即学习“Java免费学习笔记（深入）”；
- 定期采集 executor.getQueue().size() 和 executor.getRejectedExecutionCount()，设置阈值告警（如队列使用率 >80% 或每分钟拒绝超 10 次）。
- 结合线程池活跃线程数、平均任务耗时，判断是突发流量还是处理能力瓶颈。前者可临时扩容，后者需优化单任务性能或调整 corePoolSize。
- 对高频拒绝的任务类型做标记，在自定义拒绝处理器中打标并上报，用于后续容量规划和业务降级决策。
配置需与任务特征强绑定
没有通用最优值，只有贴合场景的合理值：
- CPU 密集型任务（如图像压缩、加解密）：队列宜小（10～100），核心线程数 ≈ CPU 核数，避免上下文切换损耗；溢出时优先丢弃或降级。
- I/O 密集型任务（如 HTTP 调用、DB 查询）：队列可稍大（500～2000），核心线程数可设为 2×CPU 核数，允许一定积压以掩盖 I/O 延迟；溢出时倾向重试或异步兜底。
- 混合型或不确定负载：用有界队列 + CallerRunsPolicy + 监控告警，留出人工干预窗口，避免自动策略误伤业务。
