Java线程池拒绝策略是系统过载时的主动调控机制，而非兜底摆设；其在线程池已关闭或活跃线程达maximumPoolSize且有界队列满时触发，四种内置策略各适配不同业务场景：AbortPolicy用于需快速失败的关键任务，CallerRunsPolicy提供反压降速，DiscardPolicy静默丢弃低优任务，DiscardOldestPolicy优先保障最新任务时效性。
Java线程池拒绝策略不是“兜底摆设”，而是系统过载时的主动调控机制。选错策略，轻则丢任务、误告警，重则雪崩或调用线程卡死。关键不在“用哪个”，而在“为什么用这个”。
拒绝策略何时真正生效
策略只在以下任一条件满足时触发：
- 线程池已 shutdown 或 terminated，再提交任务
- 活跃线程数已达 maximumPoolSize，且工作队列（必须是有界队列）已满
注意：使用无界队列（如 LinkedBlockingQueue 默认容量 Integer.MAX_VALUE）会让 DiscardPolicy、DiscardOldestPolicy 失效，AbortPolicy 和 CallerRunsPolicy 也仅在线程池关闭时才起作用——这正是阿里规约禁止用 Executors 工具类创建线程池的核心原因。
四种内置策略怎么选
AbortPolicy（默认）：抛出 RejectedExecutionException。适合需要“立即感知失败”的场景，比如支付回调校验、订单状态同步。必须配合 try-catch + 监控埋点，否则异常会直接冲垮上层调用链。
立即学习“Java免费学习笔记（深入）”；
CallerRunsPolicy：由提交任务的线程（如 Tomcat 的 worker 线程）同步执行该任务。本质是反压机制——调用方变慢，自然减少新任务涌入。适用于日志上报、异步通知等“不能丢但可延迟”的任务，但需警惕调用线程阻塞导致 Web 请求超时。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
DiscardPolicy：静默丢弃。适合完全可容忍丢失的场景，例如客户端心跳上报、非关键指标采集。不抛异常，也不打日志，务必确保已有监控能统计丢弃量，否则等于“黑盒丢任务”。
DiscardOldestPolicy：踢掉队列里最老的任务，再尝试提交当前任务。适合强时效性场景，如行情推送、实时风控规则匹配。但要注意：被踢任务可能比新任务更重要（比如先来的交易指令），慎用于金融核心链路。
真实业务怎么搭配策略
单一策略往往不够，实际常组合使用：
- 短信/邮件通知池：用 CallerRunsPolicy + 调用方超时控制（如 feign 设置 3s timeout），避免网关慢拖垮主流程
- 后台批处理池：用 AbortPolicy + 自定义 handler 封装，统一记录拒绝时间、任务类型、堆栈，触发企业微信告警
- 监控打点池：用 DiscardPolicy，但前置加滑动窗口限流（如每秒最多 100 条），从源头控量
- 实时推荐请求池：用 DiscardOldestPolicy，并把队列 size 设为 50，确保最新用户行为优先计算
所有策略都依赖合理参数：corePoolSize 和 maximumPoolSize 要区分 CPU 密集型（≈CPU核数）与 IO 密集型（≈2×CPU核数）；workQueue 必须有界，容量建议按 P99 峰值 QPS × 平均处理时长预估。
自定义策略解决任务不丢失
当业务要求“绝不丢任务”，又不能靠 CallerRunsPolicy 拖慢调用方时，需自定义策略：
- 将拒绝任务序列化后写入 Redis 或 Kafka，另起消费线程重试
- 写入本地文件暂存，进程重启后扫描恢复
- 落库 + 定时补偿任务，适合强一致性场景（如账务流水）
重点不是“存到哪”，而是“存完能否可靠恢复”。务必测试断电、OOM、磁盘满等异常下持久化是否健壮，补偿任务是否幂等。
