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()方法的那个线程）自己去执行这个任务。初看起来，这好像是个不错的折中方案，既不丢任务，也不直接报错。但细想一下，它其实是在向调用者施压，迫使调用者等待，这可能会导致整个系统的吞吐量下降，甚至产生连锁反应。我用过几次，发现它在处理瞬时高峰时表现不错，能起到一定的背压（backpressure）作用，防止系统被冲垮。但如果负载持续高企，反而会拖慢整个应用，因为提交任务的线程也被占用了，无法继续提交新任务。
3. DiscardPolicy 这个策略就比较“佛系”了，它会直接把新来的任务丢弃掉，不抛异常，也不执行。任务就这样“凭空消失”了。对我来说，这种策略适用于那些非关键、可容忍丢失的任务。比如日志记录、统计数据上报等。如果丢了一两条日志不影响核心业务，那么用它来保证核心任务的执行，是个明智的选择。但前提是你必须清楚，你真的能承受这种丢失，并且业务逻辑对任务丢失是容忍的。
4. DiscardOldestPolicy 这个策略则显得“有取有舍”，它会丢弃队列中最老的那个任务，然后尝试重新提交当前任务。如果线程池仍然饱和，这个新的任务也可能再次被拒绝（理论上会一直尝试，直到成功或再次被拒绝）。我个人觉得这个策略在处理流式数据或者需要保持最新状态的场景下很有用。比如，如果你在处理实时更新的数据，旧的数据可能已经没有价值了，丢弃它，让新的数据有机会被处理，这比直接丢弃新任务要合理得多。但同样，你需要确保你的业务逻辑可以接受旧任务的丢失，并且队列中的任务确实是按时间顺序排列的。
如何根据业务场景选择合适的线程池拒绝策略？
选择合适的拒绝策略，这没有标准答案，完全取决于你的业务需求和对系统行为的预期。这是一个权衡和取舍的过程。
关键任务，不容有失： 如果你的任务是核心业务流程的一部分，任何一个任务的丢失都可能导致严重的数据不一致或业务中断，那么优先考虑
AbortPolicy。它会让你立即知道系统容量不足，促使你扩容或优化。这就像一个报警器，虽然刺耳，但能及时预警，避免更严重的潜在问题。你需要在上层代码中捕获并处理
RejectedExecutionException，比如记录错误日志、触发告警或者进行熔断降级。
需要一定弹性，但不想丢任务：
CallerRunsPolicy是个选项。它能提供一种背压机制，让上游放慢速度，从而避免系统被瞬间的高并发冲垮。但要警惕它可能导致的调用链阻塞。如果你的服务是多层调用的，一个环节的
CallerRunsPolicy可能会导致整个调用链路的响应变慢。适用于那些对实时性要求不是极高，但又不能丢失任务的场景。
非核心任务，可接受丢失：
DiscardPolicy或
DiscardOldestPolicy。例如，日志记录、监控数据采集、非实时的通知发送等。如果系统过载，丢弃一些不那么重要的信息，确保核心业务运行。
DiscardOldestPolicy更适用于那些有时间敏感性的数据，新的数据比旧的数据更有价值的场景，比如实时统计数据的更新。选择这种策略时，一定要确保业务方已经明确接受了任务可能被丢弃的风险。
自定义策略： 当上述标准策略都无法满足你的特殊需求时，你可以实现
RejectedExecutionHandler接口来定义自己的拒绝逻辑。这是高级用法，当你发现标准策略都无法满足需求时，可以自己定义一套复杂的处理逻辑，比如将任务持久化到MQ或数据库，稍后重试。这给了我们极大的灵活性，但实现起来也更复杂，需要考虑更多细节。
个人观点是，在选择策略时，首先要明确任务的优先级和对失败的容忍度。其次，要考虑拒绝后对整个系统链条的影响，是希望快速失败，还是希望通过降级、重试等方式来保证最终一致性。
自定义线程池拒绝策略有哪些实际应用和实现考量？
当内置的四种拒绝策略无法满足我们特殊的业务需求时，自定义拒绝策略就显得尤为重要。它提供了一个强大的扩展点，让我们能够根据具体场景，灵活地处理那些被线程池拒绝的任务。
实现方式： 自定义拒绝策略非常直接，只需要实现
java.util.concurrent.RejectedExecutionHandler接口，并重写其唯一的
rejectedExecution(Runnable r, ThreadPoolExecutor executor)方法即可。在这个方法里，你可以定义任何你想要的逻辑。
常见实际应用场景：
任务持久化与重试： 这是最常见的自定义策略之一。当任务被拒绝时，我们不希望它直接丢失，而是希望能够稍后重试。这时，可以将任务的信息（或者任务本身序列化后）写入到消息队列（如Kafka、RabbitMQ）或者持久化到数据库中。然后，可以由另一个消费者服务或者定时任务来消费这些持久化的任务，进行重试。这确保了任务的最终一致性，但增加了系统的复杂性和潜在的延迟。
降级处理： 在系统负载过高时，可以对被拒绝的任务进行降级处理。比如，如果一个复杂的任务无法执行，可以将其简化为一个更轻量级的任务，或者只处理其中最关键的部分。例如，一个图像处理任务，在饱和时可以只进行缩略图生成，而不进行全尺寸高清处理。
资源释放： 如果被拒绝的任务在创建时已经持有了一些外部资源（如数据库连接、文件句柄等），那么在自定义拒绝策略中，可以考虑释放这些资源，避免资源泄露。
告警与监控： 记录被拒绝的任务信息，触发告警，并通过监控系统实时查看拒绝情况。这对于及时发现系统瓶颈、进行容量规划和故障排查非常有帮助。你可以将拒绝事件发送到日志系统、监控平台（如Prometheus、Grafana）或者直接通过邮件/短信发送告警。
熔断与限流： 自定义策略也可以与熔断、限流机制结合。当拒绝率达到一定阈值时，可以触发上游服务的熔断，或者通知限流组件进行更严格的限制，从而保护整个系统。
实现考量：
-
线程安全： 自定义策略的实现必须是线程安全的，因为
rejectedExecution
方法可能会被多个线程并发调用。 - 性能开销： 策略执行的逻辑不宜过于复杂，避免引入新的性能瓶颈。如果自定义策略内部涉及到耗时的IO操作（如写入数据库或发送MQ），需要特别注意其性能影响，否则可能会适得其反，导致拒绝处理本身成为瓶颈。
- 幂等性： 如果任务会被重试，需要考虑任务的幂等性。即便是重复执行多次，也应该产生相同的结果，避免重复执行造成副作用。
- 异常处理： 在自定义策略内部也要做好异常处理，防止策略本身抛出异常导致更严重的问题。例如，如果向MQ发送消息失败了，应该有相应的回退机制。
- 日志记录： 详细的日志记录对于排查问题至关重要。在拒绝策略中记录任务信息、拒绝原因等，能够帮助我们更好地理解系统行为。
一个简化的自定义拒绝策略示例：
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
： 这种策略虽然会抛出异常，看起来似乎很不稳定，因为它可能导致程序中断。但从另一个角度看，它是一种“快速失败”（fail-fast）机制，能迅速暴露系统瓶颈，避免问题蔓延。如果你的系统设计能很好地捕获并处理这些异常（比如通过熔断器、降级策略来响应），它反而能提升整体稳定性，因为它强制你及时发现并解决容量问题，而不是让问题悄无声息地积累。它就像一个健康监测器，一旦发现异常立即报警。 -
CallerRunsPolicy
： 这种策略看似温和，因为它不丢任务也不抛异常。但它可能导致调用线程阻塞，进而影响整个调用链。如果上游服务也依赖这个调用线程，就可能形成级联故障，导致整个系统吞吐量直线下降，甚至出现“死锁”般的停滞。我曾见过因为这个策略，导致一个微服务集群在面对瞬时高峰时，整体响应缓慢，最终触发了大量的超时错误。它的风险在于，它将过载压力从线程池转移到了调用方，如果调用方无法承受，整个链路都会受影响。 -
DiscardPolicy
/DiscardOldestPolicy
： 这两种策略通过丢弃任务来维持核心服务的运行，这在一定程度上保证了系统的“存活”和响应性。但代价是业务数据可能不完整，或者丢失了部分重要信息。如果业务对数据完整性有严格要求，这种“稳定”是虚假的，因为它牺牲了业务的正确性。然而，对于一些非关键、可容忍丢失的任务，它们确实能有效避免系统因任务堆积而崩溃。
对系统性能的影响：
-
直接丢弃任务的策略（
DiscardPolicy
、DiscardOldestPolicy
）： 通常对性能影响最小，因为它们不需要额外的处理开销。只是简单地将任务从内存中移除。 -
AbortPolicy
： 性能开销主要在于异常的生成和捕获。在高并发下，异常的频繁抛出和栈追踪也会带来不小的负担。虽然JVM对异常处理进行了优化，但过多的异常仍然会消耗CPU和内存资源。 -
CallerRunsPolicy
： 它的性能影响在于它将任务执行的开销转移到了调用线程，这会降低调用者的响应速度，从而间接影响整个系统的吞吐量。调用线程被阻塞，就无法及时提交新的任务，导致整个处理流程变慢。 - 自定义策略： 性能影响则取决于其内部逻辑的复杂性。例如，如果自定义策略涉及到网络IO（如发送MQ消息）、磁盘IO（如持久化到数据库）或者复杂的计算，那么其性能开销会显著增加。你需要仔细评估这些额外操作对系统性能的影响，确保拒绝处理本身不会成为新的瓶颈。
个人体会： 拒绝策略的选择，本质上是在“可用性”、“一致性”和“性能”之间做权衡。没有银弹，只有最适合你当前业务场景的策略。在设计系统时，务必结合压力测试，观察不同策略下的系统行为，才能做出最明智的决策。一个好的拒绝策略，不仅仅是处理异常情况，更是系统韧性（resilience）设计的重要一环。它能帮助你的系统在面对不可预测的高负载时，依然能够保持一定的服务能力，或者至少能够优雅地失败。
