一、引言 线程池是高并发场景下的核心组件,而拒绝策略则是线程池满载时的"安全阀"。很多开发者对四种拒绝策略的理解停留在理论层面,今天我们用真实数据说话,对比四种策略在相同压力下的表现。 测试条件: 核心线程:4 最大线程:8 队列容量:100 并发请求:200 任务耗时:模拟 100ms IO 操作 二、四种拒绝策略原理剖析 2.1 AbortPolicy(默认策略) 直接抛出 RejectedExecutionException 异常。 public static class AbortPolicy implements RejectedExecutionHandler { public AbortPolicy() {} public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { throw new RejectedExecutionException( "Task " + r.toString() + " rejected from " + e.toString()); } } 特点: 快速失败,吞吐量....
SpringBoot + 异步任务线程池满拒绝策略优化:默认 AbortPolicy 导致请求丢失?
一、线程池满的痛点 上周,一位做电商系统的朋友向我求助:他们的订单履约系统在高峰期经常丢失订单,导致大量用户投诉。 "我们使用了异步任务来处理订单,"朋友焦急地说,"但高峰期总是有任务被丢弃,订单状态一直处于'处理中',用户频繁投诉。" 我查看了他们的代码,发现问题确实很严重: 系统使用 @Async 注解处理异步任务 线程池核心线程数 10,最大线程数 20 使用默认的 AbortPolicy 拒绝策略 高峰期任务提交速度超过处理速度 被拒绝的任务直接被丢弃,没有任何记录 更关键的是,他们根本不知道有多少任务被丢弃,是被丢弃了还是正在排队? 二、传统方案的局限性 1. 默认 AbortPolicy 当线程池满了,新任务会被直接拒绝并抛出 RejectedExecutionException。 @Bean(name = "taskExecutor") public Executor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePool....
