java线程池拒绝策略是主动暴露压力、触发降级、防止雪崩的调控开关，前提是配置有界队列+合理maxpoolsize；abortpolicy适合核心链路需熔断重试，callerrunspolicy用于天然反压但禁用远程调用，discardoldestpolicy适配强时效场景，discardpolicy仅限可丢弃任务，且必须协同前置限流、任务瘦身与可观测驱动响应。
Java 线程池拒绝策略在流量洪峰中不是“扛住请求”的工具，而是主动暴露压力、触发降级、防止雪崩的调控开关。它真正起作用的前提是：线程池已配置为**有界队列 + 合理的 maxPoolSize**，且任务提交速率确实超出了系统可持续处理能力。
必须先让拒绝策略能被真正触发
很多系统在洪峰时“没触发拒绝”，不是策略无效，而是配置失当：
- 用 LinkedBlockingQueue()（无参构造） → 队列容量为 Integer.MAX_VALUE，几乎永不触发拒绝，最终堆内存耗尽、GC 频繁、系统假死
- 用 Executors.newFixedThreadPool() → 隐式使用无界队列，违反阿里规约，也掩盖真实负载
- 正确做法：显式使用 ArrayBlockingQueue(200) 或 LinkedBlockingQueue(500)，容量设为 maxPoolSize 的 1～2 倍，确保队列满 + 线程满时能及时拦截
四种策略在洪峰中的实战定位
选哪个不看文档描述，而看它对上游调用方的影响是否可控：
- AbortPolicy（默认）：抛 RejectedExecutionException。适合核心链路（如支付创建订单），要求调用方必须捕获并走熔断或重试，避免静默失败导致资损
- CallerRunsPolicy：由 Tomcat/NIO 线程同步执行任务。天然反压——提交越快，调用线程越慢，自动降低入口 QPS。秒杀场景常用，但需确保任务内不含远程调用、DB 查询或长耗时操作
- DiscardOldestPolicy：丢队列里最老的任务，再尝试提交当前任务。适合行情、推送等强时效性场景，保证最新请求不被积压淹没
- DiscardPolicy：静默丢弃。仅用于日志、埋点等可丢失任务，且必须配套监控（如每秒拒绝数突增 5 倍立即告警）
光靠拒绝策略远远不够：三道协同防线
拒绝策略只是最后一环，真正在洪峰中保系统，得靠组合动作：
- 前置限流：在网关（如 Spring Cloud Gateway）或 API 入口用 Sentinel / Resilience4j 控制 QPS 或并发数，不让超额流量抵达线程池
- 任务瘦身：秒杀下单任务只做 Redis 扣库存 + 发 MQ，绝不在此线程池里执行 JDBC；数据库写入交给独立消费线程池
- 可观测驱动响应：实时监控 getActiveCount() 和 getQueue().size()，当队列使用率持续 > 80% 或拒绝率 > 10%，自动触发降级开关（如返回“系统繁忙”）
自定义策略的关键守则
若需增强可观测性或补偿能力，自定义拒绝策略必须遵守：
- 轻量：拒绝逻辑内不能打聚合日志、不能同步发 HTTP 告警、不能操作共享 Map/List，否则会卡住所有后续 submit()
- 异步解耦：记录 traceId、任务类型、队列大小后，把告警、指标上报、延迟重试等重操作扔进独立线程池或 Kafka
- 可分级响应：核心任务拒绝走 P0 电话告警；非核心任务拒绝仅记 Prometheus 指标；丢弃类任务拒绝不告警但持续采样分析丢弃模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
