1. 项目概述线程池拒绝策略的“守门员”角色在Java并发编程的世界里线程池是我们管理多线程任务、提升系统性能的利器。但任何资源都不是无限的线程池也不例外。想象一下你开了一家网红餐厅厨房核心线程是固定的临时工非核心线程也有限制等待区工作队列的座位也坐满了。这时候门口还不断有新的顾客任务涌进来你该怎么办是粗暴地把人赶走还是让顾客自己等或者让经理亲自上阵这个“怎么办”的决策机制在Java线程池里就是拒绝策略Rejection Handler。今天我们就来深入聊聊Java线程池自带的四个内置拒绝策略AbortPolicy、CallerRunsPolicy、DiscardPolicy和DiscardOldestPolicy。这不仅仅是面试八股文里的几个名词更是你在设计高并发、高可靠系统时必须掌握的“生存法则”。理解它们你就能在资源耗尽时优雅地控制系统的行为而不是让程序直接崩溃或者悄无声息地丢失数据。我会结合源码和实际场景带你弄懂每个策略的脾气秉性、适用场景以及那些官方文档里不会写的“踩坑”经验。2. 线程池拒绝策略的核心原理与触发条件在深入四个策略之前我们必须先搞清楚拒绝策略什么时候会登场它不是随时都在的“保安”而是只在特定紧急情况下启动的“应急预案”。2.1 线程池的“满载”判定逻辑一个线程池能否接收新任务取决于其内部三个关键组件的状态核心线程池corePoolSize、工作队列workQueue和最大线程池maximumPoolSize。ThreadPoolExecutor提交任务execute方法的核心逻辑可以用一个简化的流程图来理解但更重要的是理解其背后的代码逻辑。当你调用executor.execute(runnable)时内部大致遵循以下顺序检查运行线程少于核心线程数corePoolSize立即创建新的工作线程即使有其他空闲线程来执行这个任务。这是最高优先级。线程池正在运行且任务成功加入工作队列如果核心线程已满但队列未满任务会被放入队列等待。队列已满但线程数小于最大线程数maximumPoolSize尝试创建新的非核心线程来执行这个任务。队列已满且线程数已达最大值此时线程池真正“满载”拒绝策略的RejectedExecutionHandler将被调用。关键点在于创建新线程无论是核心还是非核心的优先级高于入队。只有当前运行线程数大于等于corePoolSize时才会尝试将任务入队。而只有队列也满了才会去尝试创建超出核心线程数的线程直到maximumPoolSize。当这两条路都走不通时拒绝策略才是最后的选择。注意这里有个常见的误解认为“核心线程满了就入队队列满了就扩容到最大线程数”。实际上JDK的默认实现ThreadPoolExecutor是只要当前线程数 corePoolSize就创建新线程核心不管队列空不空。只有 corePoolSize才尝试入队。队列满了才尝试创建非核心线程。这个顺序对理解拒绝策略的触发时机至关重要。2.2 拒绝策略的接口定义所有拒绝策略都实现了java.util.concurrent.RejectedExecutionHandler接口这个接口只有一个方法void rejectedExecution(Runnable r, ThreadPoolExecutor executor);当线程池无法接受新任务时就会调用这个方法。参数r是被拒绝的任务executor是当前线程池的引用。四个内置策略就是对这个方法的不同实现。你可以通过ThreadPoolExecutor的构造函数或者setRejectedExecutionHandler方法来设置。3. 四大内置拒绝策略深度解析与实战对比了解了触发机制我们就像认识了四个性格迥异的“守门员”。下面我们逐一拆解看看他们各自如何应对“客流超载”。3.1 AbortPolicy直接抛出异常的“严格保安”这是ThreadPoolExecutor默认的拒绝策略。它的行为非常直接当无法处理新任务时直接抛出RejectedExecutionException运行时异常。源码一瞥JDK 17public static class AbortPolicy implements RejectedExecutionHandler { public AbortPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { throw new RejectedExecutionException(Task r.toString() rejected from e.toString()); } }行为解读 就像餐厅门口立了块“客满勿入”的牌子来一个新顾客就直接告知“没位置了请回吧”并且会大声嚷嚷抛出异常让整个系统调用方都知道这个情况。适用场景对任务完整性要求极高的系统比如支付交易、订单创建。宁可失败明确告知也不能默默丢弃以便上游系统能够捕获异常并进行重试或补偿。需要快速失败Fail-Fast的场景当系统负载已经过高时快速抛出异常可以防止任务堆积导致雪崩让调用方立即感知到后端压力从而采取降级或限流措施。开发和测试环境便于快速发现线程池配置不合理如队列太小、最大线程数不足的问题。实操心得与避坑指南异常处理是必须的使用AbortPolicy调用execute()方法的地方一定要做好异常处理。但要注意execute()方法本身不抛出受检异常RejectedExecutionException是运行时异常。通常需要在任务提交的代码块外围进行捕获或者使用Future并通过get()方法获取执行异常。不是所有任务提交都会抛异常只有在rejectedExecution方法被调用时才会抛。如果任务在队列中等待时线程池被关闭shutdown任务会被静默丢弃取决于关闭策略。自定义异常信息你可以继承AbortPolicy重写rejectedExecution方法在抛出异常前记录更详细的日志如任务内容、线程池状态这对于后期排查问题非常有帮助。// 自定义带日志的AbortPolicy public class LoggingAbortPolicy extends AbortPolicy { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { log.warn(Task rejected: poolSize{}, activeThreads{}, queueSize{}, completedTasks{}, executor.getPoolSize(), executor.getActiveCount(), executor.getQueue().size(), executor.getCompletedTaskCount()); super.rejectedExecution(r, executor); // 最终仍抛出异常 } }3.2 CallerRunsPolicy让调用者亲自下场的“经理”这个策略的名称直译就是“调用者运行策略”。当线程池饱和时它不会拒绝任务也不会将任务丢弃而是让提交任务的线程调用者线程自己去执行这个任务。源码一瞥public static class CallerRunsPolicy implements RejectedExecutionHandler { public CallerRunsPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { if (!e.isShutdown()) { r.run(); // 注意这里是 run()不是 start()直接在调用者线程同步执行。 } } }行为解读 餐厅满了经理调用者线程亲自出来把新顾客带到后厨一个小角落亲自为他服务。虽然慢了点但保证了顾客任务不被拒绝。关键是当经理在服务时他就没法再去门口拉新顾客了调用者线程被占用这无形中降低了新任务提交的速度给了线程池一个喘息的机会。适用场景不允许任务丢失且可以接受同步执行的场景例如一些重要的日志记录、非核心但必须完成的清理任务。天然的“反馈式”限流器这是CallerRunsPolicy最精妙的作用。当线程池满载时让调用者线程执行任务会拖慢任务提交速度因为提交线程被阻塞了从而形成一个负反馈循环有效地平缓了流量洪峰。适用于生产者速度过快需要一种简单机制来反压Backpressure的场景。需要保证任务执行顺序的某些情况由于任务在调用者线程同步执行它实际上和后续提交的任务之间产生了同步关系。实操心得与避坑指南小心调用者线程的身份如果调用者线程是Web服务器的请求处理线程如Tomcat的HTTP线程那么让这个线程去执行一个耗时任务将是灾难性的它会阻塞整个请求响应导致服务可用性急剧下降。因此在Web应用或RPC服务等需要快速响应的场景中慎用此策略。可能引起死锁或性能瓶颈如果调用者线程本身持有某些锁而它要执行的任务又需要获取其他锁可能会造成死锁。或者如果多个调用者线程同时执行任务可能会耗尽调用者线程资源。检查线程池状态从源码可以看到它在执行前会检查!e.isShutdown()。这意味着如果线程池已经关闭它会直接丢弃任务。这一点和AbortPolicy不同关闭后提交任务也会抛异常。3.3 DiscardPolicy默默丢弃的“佛系保安”这个策略最简单粗暴当无法处理任务时直接丢弃不做任何通知就像什么都没发生过一样。源码一瞥public static class DiscardPolicy implements RejectedExecutionHandler { public DiscardPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { // 空空如也直接返回 } }行为解读 餐厅满了保安悄悄把新来的顾客推到一边不声张顾客自己可能都没察觉就被忽略了。任务被静默丢弃没有任何日志没有异常。适用场景极其有限通常只适用于那些完全无足轻重、丢弃了也绝对不会有任何影响的任务。例如某些周期性的、非关键的状态采样或调试信息收集。在实际生产环境中几乎找不到推荐使用它的理由因为静默丢失数据是运维和调试的噩梦。实操心得与避坑指南强烈不推荐在生产环境使用任务丢失却无迹可寻一旦发生业务问题排查将异常困难。你无法区分是任务没提交成功还是提交后被丢弃了。如果非要使用必须包装如果真的因为某些历史原因或特殊场景要用务必自定义一个策略至少在丢弃前记录一条警告日志。public class LoggingDiscardPolicy implements RejectedExecutionHandler { private static final Logger log LoggerFactory.getLogger(LoggingDiscardPolicy.class); Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { log.warn(Task {} was silently discarded. Thread pool is saturated., r); // 这里可以添加监控指标上报如丢弃任务计数 } }3.4 DiscardOldestPolicy弃车保帅的“现实主义者”这个策略会选择丢弃工作队列中最早未处理的任务即队列头部的任务然后尝试将当前被拒绝的任务重新加入队列。源码一瞥public static class CallerRunsPolicy implements RejectedExecutionHandler { public CallerRunsPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { if (!e.isShutdown()) { e.getQueue().poll(); // 丢弃队列头部的任务 e.execute(r); // 重新尝试执行当前任务 } } }行为解读 餐厅等待区坐满了人保安让等了最久的那位顾客队列头任务离开然后把新来的顾客当前任务安排到那个空位上。这是一种“牺牲老任务保全新任务”的策略。适用场景新任务比旧任务优先级更高的场景例如一个实时数据流处理系统最新的数据样本比旧的数据样本价值更高。丢弃一些稍旧的数据确保系统能处理最新的数据。允许一定数据丢失的消息处理在某些消息队列消费者场景中如果处理速度跟不上生产速度可以选择丢弃一些积压的旧消息防止延迟无限增长。缓存更新任务如果一个键的缓存更新任务还在队列中等待又来了一个针对同一键的更新任务那么丢弃旧的可能是有意义的因为只需要最新的状态。实操心得与避坑指南小心任务依赖和顺序如果队列中的任务有严格的执行顺序或依赖关系丢弃队首任务可能导致后续任务出错或状态不一致。例如任务A生成数据任务B消费该数据如果A被丢弃B就会失败。可能造成“饥饿”现象在持续高负载下DiscardOldestPolicy可能导致某些任务永远得不到执行刚入队不久就被更新的任务挤掉形成“饥饿”。它不保证新任务一定能入队源码中丢弃队首任务后它调用e.execute(r)重新提交。注意这个execute调用可能再次失败从而再次触发拒绝策略在默认的AbortPolicy下这会导致抛出异常。但在DiscardOldestPolicy自身的rejectedExecution方法里如果execute再次失败它不会递归调用自己而是会走线程池默认的拒绝流程如果没设置就是AbortPolicy。这可能导致行为的不确定性。更安全的自定义实现应该在重试前进行更严格的判断。4. 线程池配置与拒绝策略选型实战指南知道了每个策略的特点如何为你的应用选择合适的策略呢这离不开对线程池其他参数的协同配置。4.1 核心参数对拒绝策略的影响拒绝策略不是孤立工作的它与以下几个核心参数紧密相关corePoolSize核心线程数线程池长期维持的线程数量。设置过小会频繁创建销毁线程设置过大浪费资源。它决定了线程池的“常备军”规模。maximumPoolSize最大线程数线程池允许创建的最大线程数量。它与corePoolSize的差值就是“临时工”的数量。这个值直接影响了触发拒绝策略的阈值。workQueue工作队列任务的缓冲队列。常见的队列有LinkedBlockingQueue无界队列除非资源耗尽否则不会触发拒绝策略。风险是可能堆积大量任务导致内存溢出。ArrayBlockingQueue有界队列队列满后会触发创建非核心线程进而可能触发拒绝策略。这是最常与拒绝策略搭配使用的队列类型。SynchronousQueue同步移交队列不存储元素每个插入操作必须等待另一个线程的移除操作。这会导致任务提交时如果没有空闲线程就会立即尝试创建新线程直到maxPoolSize因此很容易触发拒绝策略。适用于要求低延迟、线程数可弹性伸缩的场景。PriorityBlockingQueue优先级队列按优先级处理任务但队列无界同样有OOM风险。配置组合示例分析核心线程数最大线程数队列类型/容量拒绝策略典型行为55LinkedBlockingQueue无界AbortPolicy固定大小线程池。队列无限增长几乎不会触发拒绝策略但可能导致OOM。510ArrayBlockingQueue(100)CallerRunsPolicy弹性线程池。先使用5个核心线程任务入队至100个队列满后扩容到10个线程线程全满且队列满后由调用者线程执行。010SynchronousQueueAbortPolicy可缓存线程池类似Executors.newCachedThreadPool。没有核心线程任务直接尝试创建线程执行最多10个无空闲线程且无法创建新线程时立即拒绝。4.2 根据业务场景选择拒绝策略选择拒绝策略的本质是在任务重要性、系统可用性和响应速度之间做权衡。关键业务系统如交易、订单首选AbortPolicy。配合有界队列和合理的线程数。必须在上游做好异常捕获和重试机制例如将任务暂存到数据库或消息队列稍后重试。队列建议使用有界ArrayBlockingQueue容量根据业务吞吐量和可接受延迟设定。监控告警必须监控线程池的活跃线程数、队列大小当拒绝次数大于0时立即触发告警。计算密集型或异步处理系统如数据分析、文件处理可考虑CallerRunsPolicy。前提是调用者线程不是关键路径如不是HTTP请求线程。它可以实现简单的反压。或者DiscardOldestPolicy。如果新任务的价值远高于旧任务。但必须确保丢弃旧任务无副作用。队列建议根据任务特性选择。如果是长任务队列不宜过大防止积压。可丢失的辅助任务如非关键日志、行为采集可考虑自定义的LoggingDiscardPolicy记录日志后丢弃。绝对不要用原生的DiscardPolicy。队列建议可以使用无界队列但要设置合理的线程数并监控队列增长防止意外情况导致内存问题。4.3 自定义拒绝策略的最佳实践内置策略不满足需求时自定义策略是必然选择。以下是几个实用的自定义方向将任务持久化这是最可靠的做法。在rejectedExecution方法中将被拒绝的任务存入数据库、Redis或发往消息队列如Kafka、RocketMQ等待系统负载降低后再异步取出执行。public class PersistToQueuePolicy implements RejectedExecutionHandler { private final BlockingQueueRunnable fallbackQueue new LinkedBlockingQueue(); private final ExecutorService recoveryExecutor Executors.newSingleThreadExecutor(); public PersistToQueuePolicy() { // 启动一个单独的线程从 fallbackQueue 中取出任务重新提交到原线程池 recoveryExecutor.submit(() - { while (!Thread.currentThread().isInterrupted()) { try { Runnable task fallbackQueue.take(); // 这里可以尝试重新提交到原线程池或者另一个备用的线程池 // originalExecutor.submit(task); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }); } Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { log.warn(Task rejected, persisting to fallback queue.); if (!fallbackQueue.offer(r)) { log.error(Fallback queue is also full, task will be lost: {}, r); } } }动态扩容在拒绝时尝试临时增加maximumPoolSize注意有系统资源上限或者将任务路由到备用的线程池执行。这需要非常小心避免失控。丰富的监控与告警无论采用哪种策略在自定义的拒绝策略中加入详细的日志记录和指标上报如到Prometheus是必不可少的。记录被拒绝的任务特征、线程池当前状态大小、队列深度、活跃数等便于事后分析和容量规划。5. 生产环境常见问题排查与调优实录理论结合实践下面分享几个我在实际运维中遇到的典型问题及解决思路。5.1 问题一服务间歇性超时日志中发现大量RejectedExecutionException现象一个Web服务在晚高峰时段接口响应时间飙升并伴随大量失败。查看日志发现来自业务异步处理线程池的RejectedExecutionException。排查过程检查线程池配置发现配置为corePoolSize5, maxPoolSize10, workQueueLinkedBlockingQueue拒绝策略为默认的AbortPolicy。这里第一个问题使用了无界队列。理论上无界队列很难触发拒绝策略。分析堆栈和任务异常堆栈显示任务是一个数据库批量插入操作。进一步分析发现该任务内部会创建大量临时对象。查看JVM内存监控发现在异常发生的时间点附近有频繁的Full GC。真相大白根本原因不是队列满了而是内存不足。当JVM内存紧张尤其是即将发生Full GC时尝试创建新的线程Thread对象或者为任务分配内存可能会失败线程池在执行execute方法内部的某些步骤如创建新的工作线程时可能因为资源不足而抛出RejectedExecutionException。无界队列堆积了大量任务消耗了过多内存加剧了GC压力。解决方案将无界队列改为有界队列例如ArrayBlockingQueue(1000)。这限制了任务积压的上限防止内存被无限占用。调整拒绝策略根据业务重要性可以改为CallerRunsPolicy如果调用者线程可阻塞或自定义的持久化策略。在本案例中由于是批量插入允许一定延迟我们采用了自定义策略将拒绝的任务信息存入Redis list由另一个低优先级线程池慢慢消费。优化任务本身对批量插入任务进行分片减少单次任务的内存占用。5.2 问题二使用CallerRunsPolicy导致主线程阻塞整个服务无响应现象一个后台任务处理服务使用了CallerRunsPolicy。某次数据量激增后服务监控显示所有接口响应时间变长最终几乎无响应。排查过程检查线程池该线程池用于处理计算密集型任务corePoolSizeCPU核心数队列较小。查看调用链路发现提交任务的“调用者线程”是Spring的定时任务线程Scheduled。这个线程池是Spring管理的线程数量有限。分析当业务线程池饱和后CallerRunsPolicy开始生效。定时任务线程开始同步执行那些被拒绝的计算任务。这些计算任务耗时很长导致定时任务线程被长时间占用。而系统中很多其他定时任务都在等待这个公共的定时任务线程池从而引发了连锁反应整个系统的定时调度被拖垮。解决方案更换拒绝策略在这种“调用者线程是重要共享资源”的场景下CallerRunsPolicy是危险的。我们将其改为AbortPolicy并在任务提交层增加了简单的重试机制带指数退避。隔离线程池为不同的定时任务或不同类型的任务分配独立的线程池避免资源竞争导致级联故障。5.3 线程池监控与调优指标要防患于未然必须对线程池进行监控。以下是一些关键指标指标获取方法健康标准与调优建议活跃线程数 (ActiveCount)executor.getActiveCount()长期接近maximumPoolSize说明线程池繁忙可能需要扩容或优化任务。线程池当前大小 (PoolSize)executor.getPoolSize()应介于corePoolSize和maximumPoolSize之间。长期等于max说明负载高。队列大小 (QueueSize)executor.getQueue().size()对于有界队列持续大于容量的70%是预警信号。对于无界队列需监控其增长趋势防止OOM。已完成任务数 (CompletedTaskCount)executor.getCompletedTaskCount()与提交任务数结合可以计算吞吐量。拒绝次数需自定义拒绝策略统计最重要的指标之一。大于0即表示线程池已过载需要立即关注。调优经验公式仅供参考需压测验证CPU密集型任务计算为主corePoolSize ≈ CPU核数。maxPoolSize可以等于或略大于corePoolSize因为创建过多线程反而会因上下文切换降低性能。队列可选有界队列容量不宜过大。IO密集型任务网络、DB操作corePoolSize可以设置得大一些例如2 * CPU核数。maxPoolSize可以更大因为线程大部分时间在等待。队列容量也可以适当增大。混合型任务需要根据实际情况压测。一个方法是corePoolSize CPU核数 * 目标CPU利用率 * (1 平均等待时间/平均计算时间)。这是利特尔法则Little‘s Law在线程池中的一种应用思路但参数很难精确估计压测是最可靠的手段。最后我个人在实际操作中的体会是线程池和拒绝策略的配置没有银弹。它严重依赖于具体的业务场景、流量模式、任务特性和系统资源。最好的方法是从小配置开始辅以完善的监控和告警通过压力测试找到瓶颈然后逐步调整优化。将AbortPolicy作为默认选择是一个保守但安全的态度因为它迫使你在系统过载时直面问题而不是掩盖问题。而一个记录详尽的、自定义的拒绝策略往往是生产环境系统稳定性的最后一道可靠防线。