线程池拒绝策略需匹配业务容错能力、任务重要性与系统承载边界，错误选择会导致任务丢失或雪崩；应按任务价值（关键/非关键）、时效性（新旧优先）、稳定性要求（是否抛异常）及线程池配置联动选型，并推荐自定义策略+监控告警联动。
高并发下请求涌入时，线程池拒绝策略不是“选一个就行”，而是要匹配业务容错能力、任务重要性与系统承载边界。选错策略，轻则丢任务、重则雪崩——比如默认的 AbortPolicy 在瞬时300请求压入仅100队列+50线程的池子时，每秒抛上百次异常，直接拖垮网关。
按任务价值决定是否允许丢弃
关键业务（如支付、下单）不能静默失败，必须感知并干预；非关键任务（如埋点上报、日志聚合）可容忍丢失。
- 任务绝对不可丢：选 CallerRunsPolicy，让调用线程临时执行，虽会拖慢上游，但保任务不丢、触发自然限流
- 任务可丢且无需反馈：用 DiscardPolicy，零开销丢弃，适合高频低价值数据（如监控采样）
- 要丢也得丢旧的：选 DiscardOldestPolicy，优先保留新任务，适用于行情、推送等强时效场景
按系统稳定性要求决定是否抛异常
抛异常不是目的，是手段——关键在于有没有人真正处理它。
- 有完善监控告警链路：可用 AbortPolicy，配合 try-catch 记录指标（如 threadpool.rejected），实现快速过载发现
- 无异常捕获机制或调用方不处理：禁用 AbortPolicy，否则异常被吞，问题隐身
- 想避免级联崩溃：避免 CallerRunsPolicy 在核心接口中滥用，防止主线程阻塞引发整体响应延迟飙升
拒绝策略必须和线程池配置联动
单独调优策略没用，它只在“队列满 + 线程达最大数”时触发，而这个状态由 corePoolSize、maximumPoolSize 和队列类型共同决定。
- 用 SynchronousQueue 时，拒绝策略几乎必然触发，适合配 CallerRunsPolicy 或 DiscardPolicy，逼迫快速扩容或降级
- 用大容量 LinkedBlockingQueue 时，AbortPolicy 容易掩盖真实瓶颈——任务全堆在队列里，响应时间悄悄变长
- IO 密集型服务建议配小队列 + 合理 maximumPoolSize + CallerRunsPolicy，防积压；CPU 密集型应禁用队列或设极小值，靠拒绝策略快速反馈过载
生产环境推荐组合：自定义 + 监控联动
内置策略够用，但线上需要可观测性和主动干预能力。
- 封装自定义拒绝策略，在拒绝时打标（如 taskType=order）、记录堆栈、上报 Prometheus 指标
- 把拒绝次数接入告警规则（如 1分钟内 > 5次立即通知），而不是等服务不可用才发觉
- 搭配线程池运行时监控（activeCount、queueSize、largestPoolSize），拒绝发生时能立刻判断是突发流量还是资源长期不足
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
