ThreadPoolExecutor的拒绝策略有四种：AbortPolicy（默认，抛异常）、CallerRunsPolicy（调用线程执行）、DiscardPolicy（直接丢弃）和DiscardOldestPolicy（丢弃最老任务）。选择策略需根据业务对任务丢失的容忍度：核心任务用AbortPolicy快速失败；可容忍延迟时用CallerRunsPolicy实现背压；非关键任务可用DiscardPolicy或DiscardOldestPolicy丢弃旧或新任务；还可自定义RejectedExecutionHandler实现持久化、降级、告警等逻辑。策略影响系统稳定性与性能：AbortPolicy暴露问题但需异常处理，CallerRunsPolicy可能阻塞调用链，丢弃策略保性能但丢数据，自定义策略灵活但需考虑线程安全、性能开销和幂等性。最终选择应在可用性、一致性和性能间权衡，并结合实际压测验证。
ThreadPoolExecutor 的饱和策略，也就是我们常说的拒绝策略，主要有四种标准实现：
AbortPolicy
CallerRunsPolicy
DiscardPolicy
DiscardOldestPolicy
当线程池的任务队列已满，并且线程池中的线程数量也达到了最大限制（
maximumPoolSize
ThreadPoolExecutor
1. AbortPolicy (默认策略) 这是最直接也最暴力的做法。当任务被拒绝时，它会直接抛出一个
RejectedExecutionException
2. CallerRunsPolicy 这个策略就显得“负责任”多了，它不会直接拒绝任务，而是让提交任务的线程（也就是调用
execute()
3. DiscardPolicy 这个策略就比较“佛系”了，它会直接把新来的任务丢弃掉，不抛异常，也不执行。任务就这样“凭空消失”了。对我来说，这种策略适用于那些非关键、可容忍丢失的任务。比如日志记录、统计数据上报等。如果丢了一两条日志不影响核心业务，那么用它来保证核心任务的执行，是个明智的选择。但前提是你必须清楚，你真的能承受这种丢失，并且业务逻辑对任务丢失是容忍的。
4. DiscardOldestPolicy 这个策略则显得“有取有舍”，它会丢弃队列中最老的那个任务，然后尝试重新提交当前任务。如果线程池仍然饱和，这个新的任务也可能再次被拒绝（理论上会一直尝试，直到成功或再次被拒绝）。我个人觉得这个策略在处理流式数据或者需要保持最新状态的场景下很有用。比如，如果你在处理实时更新的数据，旧的数据可能已经没有价值了，丢弃它，让新的数据有机会被处理，这比直接丢弃新任务要合理得多。但同样，你需要确保你的业务逻辑可以接受旧任务的丢失，并且队列中的任务确实是按时间顺序排列的。
选择合适的拒绝策略，这没有标准答案，完全取决于你的业务需求和对系统行为的预期。这是一个权衡和取舍的过程。
关键任务，不容有失： 如果你的任务是核心业务流程的一部分，任何一个任务的丢失都可能导致严重的数据不一致或业务中断，那么优先考虑
AbortPolicy
RejectedExecutionException
需要一定弹性，但不想丢任务：
CallerRunsPolicy
CallerRunsPolicy
非核心任务，可接受丢失：
DiscardPolicy
DiscardOldestPolicy
DiscardOldestPolicy
自定义策略： 当上述标准策略都无法满足你的特殊需求时，你可以实现
RejectedExecutionHandler
个人观点是，在选择策略时，首先要明确任务的优先级和对失败的容忍度。其次，要考虑拒绝后对整个系统链条的影响，是希望快速失败，还是希望通过降级、重试等方式来保证最终一致性。
当内置的四种拒绝策略无法满足我们特殊的业务需求时，自定义拒绝策略就显得尤为重要。它提供了一个强大的扩展点，让我们能够根据具体场景，灵活地处理那些被线程池拒绝的任务。
实现方式： 自定义拒绝策略非常直接，只需要实现
java.util.concurrent.RejectedExecutionHandler
rejectedExecution(Runnable r, ThreadPoolExecutor executor)
常见实际应用场景：
任务持久化与重试： 这是最常见的自定义策略之一。当任务被拒绝时，我们不希望它直接丢失，而是希望能够稍后重试。这时，可以将任务的信息（或者任务本身序列化后）写入到消息队列（如Kafka、RabbitMQ）或者持久化到数据库中。然后，可以由另一个消费者服务或者定时任务来消费这些持久化的任务，进行重试。这确保了任务的最终一致性，但增加了系统的复杂性和潜在的延迟。
降级处理： 在系统负载过高时，可以对被拒绝的任务进行降级处理。比如，如果一个复杂的任务无法执行，可以将其简化为一个更轻量级的任务，或者只处理其中最关键的部分。例如，一个图像处理任务，在饱和时可以只进行缩略图生成，而不进行全尺寸高清处理。
资源释放： 如果被拒绝的任务在创建时已经持有了一些外部资源（如数据库连接、文件句柄等），那么在自定义拒绝策略中，可以考虑释放这些资源，避免资源泄露。
告警与监控： 记录被拒绝的任务信息，触发告警，并通过监控系统实时查看拒绝情况。这对于及时发现系统瓶颈、进行容量规划和故障排查非常有帮助。你可以将拒绝事件发送到日志系统、监控平台（如Prometheus、Grafana）或者直接通过邮件/短信发送告警。
熔断与限流： 自定义策略也可以与熔断、限流机制结合。当拒绝率达到一定阈值时，可以触发上游服务的熔断，或者通知限流组件进行更严格的限制，从而保护整个系统。
实现考量：
rejectedExecution
一个简化的自定义拒绝策略示例：
import java.util.concurrent.RejectedExecutionHandler;
import java.util.concurrent.ThreadPoolExecutor;
public class CustomRejectionHandler implements RejectedExecutionHandler {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
// 比如，记录日志并放入消息队列等待重试
System.err.println("任务 " + r.toString() + " 被拒绝。正在尝试放入消息队列进行后续处理...");
// 这里可以加入实际的MQ发送逻辑，或者将任务持久化到数据库
// 例如：messageQueueService.send(r);
// 如果无法放入MQ，可以选择抛出自定义异常，或者执行降级逻辑
// throw new CustomRejectedException("任务被拒绝，且无法持久化到MQ.");
}
}
// 在创建线程池时使用这个自定义策略：
// ThreadPoolExecutor executor = new ThreadPoolExecutor(
// corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.SECONDS,
// new LinkedBlockingQueue<>(queueCapacity),
// Executors.defaultThreadFactory(),
// new CustomRejectionHandler() // 使用自定义的拒绝策略
// );拒绝策略的选择，远不止是处理一个任务那么简单，它直接关系到整个系统的健康状况，包括稳定性和性能表现。这是一个在不同层面进行权衡的决策。
对系统稳定性的影响：
AbortPolicy
CallerRunsPolicy
DiscardPolicy
DiscardOldestPolicy
对系统性能的影响：
DiscardPolicy
DiscardOldestPolicy
AbortPolicy
CallerRunsPolicy
个人体会： 拒绝策略的选择，本质上是在“可用性”、“一致性”和“性能”之间做权衡。没有银弹，只有最适合你当前业务场景的策略。在设计系统时，务必结合压力测试，观察不同策略下的系统行为，才能做出最明智的决策。一个好的拒绝策略，不仅仅是处理异常情况，更是系统韧性（resilience）设计的重要一环。它能帮助你的系统在面对不可预测的高负载时，依然能够保持一定的服务能力，或者至少能够优雅地失败。
以上就是ThreadPoolExecutor 的饱和策略（拒绝策略）有哪些？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
372
