线程池拒绝任务会中断业务，因默认abortpolicy抛rejectedexecutionexception且调用方未捕获；需自定义异步、可观察、有兜底的拒绝策略，并与线程池参数联动压测验证。
为什么线程池拒绝任务会直接中断业务
线程池拒绝任务本身不抛异常，但默认的 AbortPolicy 会在拒绝时抛出 RejectedExecutionException。如果调用方没捕获、也没做兜底（比如重试或降级），整个请求链就断了——不是线程池“挂了”，而是你没接住这个异常。
- 常见错误现象：接口偶发 500，日志里只有
java.util.concurrent.RejectedExecutionException，没其他堆栈 - 根本原因不是线程池太小，而是拒绝策略没适配业务语义：支付下单不能丢，日志上报可以丢
- 注意
execute()抛异常，submit()则把异常包进Future.get()，容易漏捕获
怎么写一个真正可用的自定义拒绝处理器
别只实现 RejectedExecutionHandler 接口就完事。关键是要让拒绝行为可观察、可控制、不阻塞主线程。
- 拒绝逻辑必须异步执行：比如发告警、写本地日志、投递到 Kafka 备份，绝不能在
rejectedExecution()里同步调远程服务 - 避免死循环：若备份队列也满，要设上限（如最多缓存 100 条）并丢弃老任务，否则内存持续增长
- 示例骨架：
public class LoggingAndFallbackPolicy implements RejectedExecutionHandler { private final BlockingQueue<Runnable> fallbackQueue = new LinkedBlockingQueue<>(100); @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 记录拒绝事实（注意别打太频繁） if (fallbackQueue.offer(r)) { // 异步消费 fallbackQueue，例如用单线程 ScheduledExecutorService 定期 drain } else { // 达上限，直接丢并告警 log.warn("Fallback queue full, dropping task: {}", r); } } }
四种内置拒绝策略的实际表现差异
不同策略对业务连续性影响天差地别，选错比不配置还危险。
-
AbortPolicy（默认）：抛RejectedExecutionException，适合强一致性场景，但要求调用方全链路处理异常 -
CallerRunsPolicy：由提交线程自己执行任务，看似“不丢”，实则可能拖慢上游（比如 HTTP 请求线程被卡住），并发高时雪崩风险大 -
DiscardPolicy：静默丢弃，适合纯异步、可丢失的任务（如埋点上报），但无任何反馈，线上难排查 -
DiscardOldestPolicy：丢队列头任务，换新任务进来——对有严格时序要求的任务（如订单状态机更新）可能引发状态错乱
线程池配置与拒绝策略必须联动验证
单独改拒绝策略没用，得和 corePoolSize、maximumPoolSize、workQueue 一起压测验证。
立即学习“Java免费学习笔记（深入）”；
- 常见坑：用
LinkedBlockingQueue且没设容量上限，结果永远不触发拒绝——表面“稳定”，实则 OOM 风险极高 - 性能影响：拒绝策略本身不该成为瓶颈，但若在其中做同步 I/O（如写文件、发 HTTP），会拖慢整个线程池的拒绝响应速度
- 兼容性注意：Spring 的
@Async默认用SimpleAsyncTaskExecutor（无队列），不走你配的线程池，拒绝策略对其无效
真正难的不是写个拒绝处理器，是搞清哪些任务绝对不能丢、哪些可以降级、哪些丢了之后有没有补偿路径。拒绝策略只是最后一道闸门，闸门之前得有水位监控、弹性扩缩、流量染色这些配套动作。
