Java线程池拒绝任务仅发生在SHUTDOWN/STOP状态或运行中队列满且线程数≥maximumPoolSize时，严格遵循核心线程→队列→非核心线程三级缓冲机制；四种内置拒绝策略各适配不同业务场景，生产环境需搭配有界队列、埋点监控与告警。
Java线程池在高负载下拒绝任务，不是随机丢弃，而是严格遵循“先用核心线程→再进队列→最后启非核心线程”的三级缓冲机制。只有当这三层全部饱和（即：活跃线程数已达 maximumPoolSize 且工作队列已满），新提交的任务才会触发拒绝策略。
拒绝发生的准确时机
任务被拒绝只发生在两个明确条件下：
- 线程池处于 SHUTDOWN 或 STOP 状态（已关闭）
- 线程池运行中，但同时满足：队列已满 + 当前线程数 ≥ maximumPoolSize
注意：即使核心线程全忙、队列未满，任务仍会进队列，不会拒绝；同样，队列满但线程数还没到上限，线程池还会继续创建非核心线程——直到触达上限才启动拒绝逻辑。
四种内置策略的行为本质
所有策略都实现 RejectedExecutionHandler 接口，但应对方式截然不同：
立即学习“Java免费学习笔记（深入）”；
-
AbortPolicy：抛出
RejectedExecutionException，强制调用方感知失败，适合强一致性场景（如支付扣款） - CallerRunsPolicy：让提交任务的线程自己执行该任务，天然限流——调用线程被占用，后续提交变慢，形成负反馈
- DiscardPolicy：静默丢弃，不抛异常也不记录，适用于可丢失、低优先级任务（如统计上报、心跳日志）
- DiscardOldestPolicy：先踢掉队列里最老的一个任务，再尝试重新提交当前任务，适合有“时效性”要求的队列（如实时行情更新）
策略选型的关键业务维度
不能只看“要不要丢任务”，而要结合系统角色和容错能力判断：
- 是否允许任务丢失？不允许 → 优先考虑 CallerRunsPolicy 或自定义持久化策略
- 能否接受调用线程阻塞？能 → CallerRunsPolicy 是简单有效的降级手段
- 是否需要快速暴露过载？是 → AbortPolicy 配合监控告警，便于及时扩容或熔断
- 任务是否有时间敏感性？是 → DiscardOldestPolicy 比单纯丢弃更合理
生产环境常见误区与加固建议
很多线上问题源于策略配置与实际负载脱节：
- 用默认 AbortPolicy 却没捕获异常，导致上游请求直接 500，掩盖了真实瓶颈
- 配了无界队列（如
LinkedBlockingQueue无参构造），看似永不拒绝，实则内存溢出风险极高 - 盲目增大 maximumPoolSize 而忽略 CPU 和 I/O 瓶颈，引发上下文切换风暴
- 未监控 getRejectedExecutionCount()（需通过自定义包装或 MBean 获取），无法量化拒绝率
建议：始终搭配有界队列 + 明确拒绝策略 + 拒绝数埋点 + 告警阈值（如每分钟拒绝超 100 次立即通知），把拒绝从故障变成可观测信号。
