线程池拒绝策略是业务流量调控的主动杠杆，而非简单丢弃开关；CallerRunsPolicy通过反压触发前端降级提示，自定义策略可实现分级导流，AbortPolicy配合监控构建自动扩缩容闭环，DiscardOldestPolicy适用于实时性敏感场景的自然削峰。

线程池拒绝策略不是兜底的“丢弃开关”，而是业务流量调控的主动杠杆。当系统接近承载极限时，合理选择并配置拒绝策略，能将技术过载转化为可感知、可引导的用户体验，实现平滑切换与流量分流。

用CallerRunsPolicy制造可控延迟，触发前端降级提示

该策略让提交任务的线程（如Web容器线程）同步执行任务，天然形成反压。用户请求不会直接失败，但响应变慢——这正是前端发起友好提示（如“系统繁忙，请稍后再试”或自动切换至轻量版页面）的理想信号窗口。

• 配置示例：核心线程2、最大4、队列容量3，搭配CallerRunsPolicy
• 效果：当第10个请求涌入，前9个按序处理，第10个由Tomcat主线程执行，耗时拉长200ms+，监控系统捕获P95延迟突增，自动触发前端灰度开关
• 关键点：需配合全链路延迟埋点与前端心跳检测，避免用户卡死无反馈

自定义拒绝策略实现分级导流与变量路由

不满足于“丢或等”，可编写策略根据任务特征动态决策：高优先级订单走补偿队列，低优先级日志类任务静默丢弃，AB测试流量按比例转发至备用通道。

• 例如：在rejectedExecution中解析任务上下文，识别请求头中的X-Traffic-Tag
• 若为canary标签，写入Kafka重试主题；若为analytics，直接return；若为payment，调用熔断器降级为预估支付结果
• 注意：自定义逻辑必须轻量，避免在拒绝路径上引入IO或锁，否则会加剧阻塞

组合AbortPolicy + 监控告警 + 自动扩缩容闭环

默认策略看似激进，实则最利于构建自动化响应。一旦抛出RejectedExecutionException，立即成为扩容指令信号。

• 在Spring Boot中捕获该异常，上报Prometheus指标threadpool_rejected_total{pool="biz"}
• 配置Grafana告警：1分钟内超过5次拒绝即触发Webhook
• Webhook调用K8s API，将对应服务的副本数从3扩至5，并临时提升队列容量配置（通过配置中心推送）
• 扩缩容后，旧实例执行优雅关闭，新实例预热加载缓存，实现无感承接

DiscardOldestPolicy用于实时性敏感场景的自然削峰

对消息推送、行情刷新等强时效任务，老数据价值快速衰减。该策略丢弃队列头部最旧任务，保障最新请求优先执行，相当于内置了“时间加权”的流量过滤器。

• 适用场景：股票行情订阅服务，每秒接收上千条报价，但用户只关心最新3秒数据
• 配置建议：搭配SynchronousQueue或极小容量ArrayBlockingQueue，强化“即产即消”特性
• 风险提示：需确保任务本身无状态依赖，避免丢弃旧任务导致后续逻辑错乱