获课：itazs.fun/2223/

#### 拒绝策略的选择：AbortPolicy、CallerRunsPolicy...哪种策略能保住你的线上服务？

在Java并发编程的教学中，线程池是绕不开的核心知识点。许多初学者往往只关注如何创建线程池、提交任务，却忽略了当系统面临“洪峰”流量，资源耗尽时该怎么办。这就好比一个繁忙的餐厅，当服务员（线程）满负荷、候客区（队列）也坐满时，新来的顾客（任务）该如何接待？是直接拒之门外，还是让迎宾员亲自去端盘子？这就是拒绝策略要解决的问题。合理选择拒绝策略，不仅是技术选型，更是系统稳定性的最后一道防线。

AbortPolicy（中止策略）是Java线程池的默认策略。它的行为非常“刚烈”：一旦线程池满了，直接抛出RejectedExecutionException异常，拒绝新任务。在教学场景中，这常被比喻为“快速失败”。这种策略适用于那些对数据一致性要求极高、不允许任何任务丢失，且调用方有能力处理异常的场景。例如在金融交易系统中，如果系统过载，直接抛出异常让前端重试或转入人工处理，比默默丢弃订单要安全得多。它像是一个严格的保安，名额满了就拉闸，防止内部系统因过载而雪崩，但代价是可能会牺牲部分用户体验。

CallerRunsPolicy（调用者运行策略）则展现了一种“温柔的反压”智慧。当线程池无法处理新任务时，它不会抛出异常，而是将任务退回到调用者线程（例如Tomcat的主线程）去执行。这就像餐厅候客区满了，经理（调用者）亲自下场去端盘子。虽然这会降低新任务提交的速度（因为经理忙着端盘子没空接客），但它有效地减缓了流量涌入，给线程池喘息的机会，且保证了任务不丢失。在教学案例中，这常用于Web网关或服务降级场景，是一种用时间换空间的自我保护机制。

相比之下，DiscardPolicy（丢弃策略）和DiscardOldestPolicy（丢弃最旧策略）则更加“冷酷”。前者直接静默丢弃新任务，后者则丢弃队列中等待最久的任务，然后尝试提交新任务。这两种策略在教学中通常被归类为“非核心业务”的处理方案。例如在日志采集、监控埋点等场景中，少量的数据丢失是可以容忍的，此时为了保住核心业务的稳定性，可以选择丢弃次要任务。如果系统追求极致的时效性，认为新任务比旧任务更有价值（如实时股票行情），那么丢弃最旧策略便是一个合理的选择。

然而，在实际的生产环境教学中，我们更强调“自定义拒绝策略”的重要性。内置的策略往往难以满足复杂的业务需求。一个成熟的线上服务，往往需要结合监控告警、熔断降级和持久化重试。例如，当任务被拒绝时，我们可以自定义策略将其写入本地磁盘或消息队列（如Kafka），待系统负载下降后再重新消费；或者触发监控报警，通知运维人员介入。这种策略不再是简单的“拒绝”，而是一种优雅的业务降级与熔断保护，它将线程池的异常处理上升到了系统治理的高度。

综上所述，拒绝策略的选择没有绝对的优劣，只有适不适合。AbortPolicy适合强一致性场景，CallerRunsPolicy适合需要自动限流的场景，Discard类策略适合非核心业务，而自定义策略则是构建高可用系统的终极武器。在教育的视角下，理解这些策略背后的权衡（Trade-off），比死记硬背API更为重要。只有根据业务特性灵活配置，才能在流量洪峰到来时，保住你的线上服务，让系统既具备高吞吐的能力，又拥有从容应对危机的韧性。