线程池拒绝策略是资源耗尽时的主动防御机制，需同时满足队列满、活跃线程达maximumpoolsize且非running状态才触发；四种策略各适配不同场景，但须配合可观测性与合理配置方能有效治理。
线程池拒绝处理程序不是故障，而是系统在资源耗尽时的主动防御机制。它不解决压力本身，但能防止雪崩——比如内存溢出、线程爆炸或响应无限延迟。
拒绝策略触发的真实条件
只有当三个条件同时满足时，拒绝策略才会被调用：
- 工作队列已满（无论有界还是无界，实际容量已触顶）
- 当前活跃线程数已达 maximumPoolSize
- 线程池未处于 RUNNING 状态（如已 shutdown 或 stop）
注意：使用无界队列（如默认 LinkedBlockingQueue）时，队列几乎不会满，线程数也很难达到 maximumPoolSize，此时拒绝策略基本不会触发——但这会掩盖真实瓶颈，导致 OOM 风险升高。
四种策略在高压下的行为差异
AbortPolicy（默认）：立即抛出 RejectedExecutionException。调用线程感知失败最快，适合需要强一致性保障的场景（如支付、转账）。但若上层未捕获，会导致服务接口直接报错。
CallerRunsPolicy：由提交任务的线程（比如 Tomcat 的 worker 线程）同步执行该任务。本质是反压机制——让上游慢下来。但若任务耗时长，会阻塞 Web 容器线程，造成整体吞吐下降甚至请求堆积。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
DiscardPolicy：静默丢弃，不抛异常、不记录、不反馈。适用于日志上报、埋点采集等“丢了也不影响主流程”的任务。高压下最轻量，但缺乏可观测性。
DiscardOldestPolicy：先移除队列头部（最早入队）任务，再尝试重新提交当前任务。适合时效敏感型数据（如行情、监控指标），但可能反复丢弃同一批老任务，形成“饥饿”现象。
极端压力下容易被忽略的关键点
拒绝策略生效时，往往意味着线程池配置与业务负载严重不匹配。仅换策略治标不治本：
- 队列过大会掩盖线程扩容不足问题；队列过小又频繁触发拒绝，浪费核心线程能力
- maximumPoolSize 设置过高，可能导致上下文切换开销激增，CPU 利用率飙升但有效吞吐不升反降
- 拒绝日志若未包含任务标识、提交时间、队列长度、活跃线程数等上下文，就无法定位是突发流量还是慢任务积压所致
生产环境推荐做法
拒绝策略必须配合可观测手段落地：
- 所有拒绝事件必须记录完整上下文，并接入监控告警（如 Prometheus + Grafana）
- 对 AbortPolicy 的 catch 块中，建议将任务转存至消息队列或本地磁盘，实现异步重试
- 对 CallerRunsPolicy，需限制单次任务执行超时（如用 Future.get(3, TimeUnit.SECONDS) 包装），避免调用线程卡死
- 避免全局复用同一套拒绝策略——核心链路用 AbortPolicy + 告警，非核心链路可用 DiscardPolicy + 采样日志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
