CallerRunsPolicy使用详解

什么是CallerRunsPolicy

在线程池的使用中，当任务提交速度超过线程池处理能力时，就会出现任务堆积。为了应对这种情况，Java 提供了几种拒绝策略，其中 CallerRunsPolicy 是一种比较特别的处理方式。

简单来说，当线程池和队列都满的时候，CallerRunsPolicy 不会直接丢弃任务，也不会抛出异常，而是让提交任务的线程自己去执行这个任务。

适用场景举例

想象一下你开了一家奶茶店，有3个固定员工（核心线程）负责做奶茶，最多能临时加2个兼职（最大线程），还有5个订单可以排队等待制作（队列容量）。突然节假日来了，顾客点单太快，员工全在忙，队列也满了。这时候新来的订单怎么处理？

如果采用 CallerRunsPolicy 策略，那就相当于让顾客自己动手做这杯奶茶——也就是由调用者线程来执行任务。这样做虽然会让顾客等得久一点（提交线程被占用），但至少没把人赶走，系统也不会崩溃。

代码示例

import java.util.concurrent.*;

public class ThreadPoolExample {
    public static void main(String[] args) {
        // 创建一个固定大小的线程池
        ExecutorService executor = new ThreadPoolExecutor(
                2,                                   // 核心线程数
                4,                                   // 最大线程数
                10, TimeUnit.SECONDS,               // 空闲线程存活时间
                new LinkedBlockingQueue<>(2),       // 队列容量为2
                new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
        );

        // 提交6个任务，超出容量
        for (int i = 0; i < 6; i++) {
            final int taskId = i;
            executor.submit(() -> {
                System.out.println("任务 " + taskId + " 正在执行，执行线程：" + Thread.currentThread().getName());
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        executor.shutdown();
    }
}

运行上面这段代码，你会发现前4个任务分别由两个核心线程和两个新增线程处理。当队列满、线程数达到最大值后，最后两个任务会被主线程（或其他提交任务的线程）直接执行，输出中的线程名可能显示为 main，这就是 CallerRunsPolicy 在起作用。

优缺点分析

这种策略的优点是平滑降级。它不会直接丢弃请求，而是通过拖慢提交方来缓解压力，相当于给系统一个“喘口气”的机会。适合对数据完整性要求较高的场景，比如日志采集、交易记录等，不能随便丢任务的地方。

但它也有明显缺点：如果提交任务的是主线程或关键业务线程，那这个线程就会被阻塞。在高并发下可能导致响应变慢，甚至连锁反应影响整个服务。

什么时候该用

当你希望系统尽可能处理所有任务，又能接受一定程度的延迟时，CallerRunsPolicy 是个不错的选择。特别是那些后台任务不太紧急、但又不想丢失的场景，比如定时同步数据、异步写文件等。

需要注意的是，配合合理的队列大小和线程数设置，才能发挥它的作用。光靠拒绝策略救不了设计不合理的问题。

实际项目中，可以结合监控手段观察拒绝频率，如果经常触发 CallerRunsPolicy，说明线程池配置需要调整，或者系统负载已经超出预期，得从根源上优化。