线程池拒绝策略详解与应用场景分析

1. 线程池拒绝策略的本质与触发条件

当线程池的核心线程数、队列容量和最大线程数都达到上限时，新的任务就会触发拒绝策略。这个机制本质上是一种资源保护手段，防止系统因过载而崩溃。我在实际项目中见过不少因为忽略拒绝策略而导致服务雪崩的案例。

线程池的工作流程可以这样理解：新任务到来时，系统首先尝试使用核心线程处理；当核心线程忙时，任务进入队列；队列满时才创建新线程（直到达到最大线程数）；当所有资源耗尽时，才会执行拒绝策略。这个流程决定了拒绝策略是系统最后的防线。

2. 四种标准拒绝策略详解

2.1 AbortPolicy：直接抛出异常

这是ThreadPoolExecutor默认的策略。当任务被拒绝时，会抛出RejectedExecutionException。这种策略适合对任务完整性要求高的场景，比如金融交易系统。

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2, 4, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(2),
    new ThreadPoolExecutor.AbortPolicy()
);

我在电商项目中曾用这种策略处理订单创建请求。当系统过载时，宁可拒绝部分请求也要保证已接受订单的正常处理。但要注意捕获异常并给用户友好提示。

2.2 CallerRunsPolicy：调用者执行策略

这个策略会让提交任务的线程自己执行被拒绝的任务。相当于让调用方临时充当线程池的工作线程。

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2, 4, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(2),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

在内容审核系统中，我们用它处理突发流量。虽然调用线程执行会降低响应速度，但保证了任务不会丢失。要注意的是，如果调用线程是Tomcat的工作线程，可能会影响整体吞吐量。

2.3 DiscardPolicy：静默丢弃策略

这个策略会直接丢弃被拒绝的任务，没有任何通知。看似简单粗暴，但在某些场景下很实用。

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2, 4, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(2),
    new ThreadPoolExecutor.DiscardPolicy()
);

在实时日志收集系统中，我们用它处理非关键日志。当系统过载时，宁可丢弃部分日志也要保证核心功能。但绝对不要把它用在支付等关键业务上。

2.4 DiscardOldestPolicy：丢弃队列最老任务

这个策略会丢弃队列中等待最久的任务，然后尝试将新任务加入队列。

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2, 4, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(2),
    new ThreadPoolExecutor.DiscardOldestPolicy()
);

在消息推送系统中，我们用这个策略保证用户总是收到最新消息。但要注意被丢弃的任务可能已经等待了很久，要做好补偿机制。

3. 自定义拒绝策略的实现

除了四种标准策略，我们可以通过实现RejectedExecutionHandler接口来自定义策略。这是我在实际项目中最常用的扩展点。

java复制public class RetryPolicy implements RejectedExecutionHandler {
    private final int maxRetries;
    private final long retryInterval;
    
    public RetryPolicy(int maxRetries, long retryInterval) {
        this.maxRetries = maxRetries;
        this.retryInterval = retryInterval;
    }
    
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        int retries = 0;
        while (retries < maxRetries) {
            try {
                Thread.sleep(retryInterval);
                if (executor.getQueue().offer(r)) {
                    return;
                }
                retries++;
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                throw new RejectedExecutionException("Interrupted while retrying", e);
            }
        }
        throw new RejectedExecutionException("Task rejected after " + maxRetries + " retries");
    }
}

在订单履约系统中，我们实现了这个带重试机制的策略。当系统暂时过载时，任务会等待后重试，大大降低了订单丢失率。但要注意设置合理的重试次数和间隔，避免长时间阻塞。

4. 拒绝策略的选型与实践经验

4.1 不同业务场景的选型建议

• 支付系统：建议使用AbortPolicy+告警机制，确保每笔交易可追踪
• 实时监控：DiscardOldestPolicy更适合，最新数据比历史数据更重要
• 批量处理：CallerRunsPolicy可以平滑处理短期峰值
• 日志收集：DiscardPolicy配合采样率控制是不错的选择

4.2 参数配置的黄金法则

根据我的经验，好的线程池配置应该遵循这些原则：

1. 核心线程数 = CPU核心数 × (1 + 平均等待时间/平均计算时间)
2. 队列容量 = 核心线程数 × 2
3. 最大线程数 = 核心线程数 × 4
4. 拒绝策略根据业务容忍度选择

4.3 常见陷阱与解决方案

问题1：使用无界队列导致内存溢出
解决：永远不要用LinkedBlockingQueue而不指定容量

问题2：DiscardPolicy导致关键任务丢失
解决：重要任务实现自己的拒绝逻辑，如持久化到数据库

问题3：CallerRunsPolicy引起调用线程阻塞
解决：在Web应用中，要为Tomcat配置合适的最大线程数

5. 高级应用场景分析

5.1 混合策略的实现

在复杂的业务系统中，我们可能需要针对不同类型的任务使用不同的拒绝策略。这时可以通过装饰器模式实现策略路由：

java复制public class RoutingPolicy implements RejectedExecutionHandler {
    private final Map<Class<?>, RejectedExecutionHandler> policyMap;
    
    public RoutingPolicy(Map<Class<?>, RejectedExecutionHandler> policyMap) {
        this.policyMap = policyMap;
    }
    
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        RejectedExecutionHandler policy = policyMap.get(r.getClass());
        if (policy == null) {
            policy = new ThreadPoolExecutor.AbortPolicy();
        }
        policy.rejectedExecution(r, executor);
    }
}

在电商平台中，我们用这个方案对订单、库存、日志等不同业务实施不同的拒绝策略。

5.2 监控与动态调整

优秀的线程池管理需要实时监控和动态调整。我们可以通过JMX暴露关键指标：

java复制public class MonitorableThreadPool extends ThreadPoolExecutor {
    private final AtomicLong rejectedCount = new AtomicLong();
    
    // 构造方法省略...
    
    @Override
    public void execute(Runnable command) {
        try {
            super.execute(command);
        } catch (RejectedExecutionException e) {
            rejectedCount.incrementAndGet();
            throw e;
        }
    }
    
    @ManagedAttribute
    public long getRejectedCount() {
        return rejectedCount.get();
    }
}

配合Prometheus和Grafana，我们可以建立完整的监控体系，当拒绝次数超过阈值时自动扩容或告警。

5.3 跨线程池的任务转移

在微服务架构中，我们可以实现更智能的拒绝策略 - 将任务转移到其他线程池：

java复制public class FallbackPolicy implements RejectedExecutionHandler {
    private final ThreadPoolExecutor fallbackPool;
    
    public FallbackPolicy(ThreadPoolExecutor fallbackPool) {
        this.fallbackPool = fallbackPool;
    }
    
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        if (!fallbackPool.isShutdown()) {
            fallbackPool.execute(r);
        } else {
            throw new RejectedExecutionException("Both primary and fallback pools are full");
        }
    }
}

这种模式在我们的大促预案中效果显著，当核心订单线程池过载时，任务会自动转移到备用池处理。