callerrunspolicy 是线程池饱和时由提交任务的调用线程同步执行任务的拒绝策略，不丢弃也不抛异常；需显式设置且满足饱和条件（线程数达最大且队列满），适用于需避免任务丢失的保护型场景。
CallerRunsPolicy 是 Java 线程池的四种内置拒绝策略之一，它的核心行为是：当线程池已满（工作队列也满了、线程数已达最大）、新任务无法被接纳时，**不丢弃任务，也不抛异常，而是由提交任务的线程（即调用 execute() 的线程）直接执行该任务**。
为什么叫“调用方执行”？
这里的“调用方”不是指某个固定类或对象，而是指当前正在调用 ThreadPoolExecutor.execute(Runnable) 方法的那个线程。比如你在主线程中调用 executor.execute(task)，而此时触发了拒绝，则这个 task.run() 就会在主线程中同步执行——而不是交给线程池里的任何 worker 线程。
它怎么生效？关键条件要满足
CallerRunsPolicy 不会自动启用，需显式设置，并且依赖线程池状态：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 必须将拒绝策略设为
new ThreadPoolExecutor.CallerRunsPolicy() - 线程池必须处于 饱和状态：即
poolSize == maximumPoolSize且workQueue.isFull() - 任务是通过
execute()提交的（submit()内部也调用execute()，所以同样适用）
典型使用方式（代码片段）
下面是一个最小可运行示例：
// 创建固定大小线程池，但队列容量极小，便于触发拒绝
ThreadPoolExecutor executor = new ThreadPoolExecutor(
1, 1, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue(1), // 队列最多存 1 个任务
new ThreadPoolExecutor.CallerRunsPolicy() // 关键：启用 CallerRunsPolicy
);
// 提交 3 个任务（此时很快就会饱和）
executor.execute(() -> { System.out.println("Task 1 by " + Thread.currentThread().getName()); });
executor.execute(() -> { System.out.println("Task 2 by " + Thread.currentThread().getName()); });
executor.execute(() -> { System.out.println("Task 3 by " + Thread.currentThread().getName()); });
executor.shutdown();
输出可能类似：
Task 1 by pool-1-thread-1 Task 2 by pool-1-thread-1 Task 3 by main ← 这个是由主线程（调用方）执行的
要注意的实际影响
这种策略看似“兜底”，但有明显副作用：
- 调用线程被阻塞：任务是同步执行的，提交线程得等任务跑完才能继续，可能拖慢上游逻辑
- 可能引发级联减速：如果大量任务被回退到调用方执行，整个系统吞吐量会下降，甚至雪崩
- 不适合高并发/低延迟场景：它不缓解压力，只是把压力转移给调用者
- 适合保护型场景：例如后台批处理、非实时任务，用它避免任务丢失，同时让调用方感知过载并自我节流
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
