什么是CallerRunsPolicy
在Java并发编程中，线程池是提升系统性能的常用手段。当线程池的任务队列已满且线程数达到最大限制时，新提交的任务需要由拒绝策略来处理。CallerRunsPolicy就是其中一种内置的拒绝策略。
它的核心行为是：当线程池无法接收新任务时，该任务不会被丢弃，而是由提交任务的线程（即调用者线程）亲自执行。这种方式看似简单，却能在某些办公网络环境下有效缓解系统压力。
为什么选择CallerRunsPolicy
想象一个常见的办公场景：公司内部的审批系统在每天上午9点集中收到大量申请，后台使用线程池处理这些请求。如果此时线程池饱和，直接抛出异常会让用户看到“系统繁忙”，体验很差。而使用CallerRunsPolicy，可以让Web容器的请求线程（如Tomcat的工作线程）自己运行这个任务。
这样做虽然会暂时拖慢当前请求的响应速度，但避免了任务丢失，也防止了下游服务被瞬间流量冲垮。相当于让发起请求的人“自己动手完成一部分工作”，而不是直接拒之门外。
代码示例
下面是一个典型的线程池配置，启用了CallerRunsPolicy：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // 核心线程数
4, // 最大线程数
60L, // 空闲线程存活时间
TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(2), // 任务队列容量为2
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);当有6个任务同时提交时，前2个由核心线程执行，中间2个进入队列，第5、6个任务由于超出容量和最大线程限制，会触发CallerRunsPolicy。此时提交第5、6个任务的主线程将直接执行它们。
适用场景建议
在办公网络环境中，CallerRunsPolicy特别适合用于那些对数据完整性要求高、但能容忍短暂延迟的业务流程。比如日志收集、报表生成、邮件通知等异步任务。这些任务如果被丢弃，可能导致信息遗漏；而由调用方线程执行，反而能起到自然的“限流”作用。
需要注意的是，这种策略会让调用线程阻塞，因此不适合用于实时性要求极高的接口。如果你的办公系统对接口响应时间非常敏感，可能需要结合其他策略或扩容方案。
与其他策略对比
相比AbortPolicy（直接抛出异常）、DiscardPolicy（静默丢弃）、DiscardOldestPolicy（丢弃最老任务），CallerRunsPolicy更温和，也更安全。它不依赖额外资源，也不造成数据丢失，在轻量级办公应用中尤为实用。
例如一个小团队使用的内部考勤统计工具，没必要引入复杂的重试机制或消息队列，直接用CallerRunsPolicy就能稳定运行。