默认AbortPolicy导致500因抛出未捕获的RejectedExecutionException，冒泡至容器线程触发错误页；应改用带日志、同步降级和限频告警的自定义策略，避免CallerRunsPolicy反压Web线程。
为什么默认的 AbortPolicy 会让线上服务突然 500？
因为它的行为是直接抛出 RejectedExecutionException，而多数 Web 框架（比如 Spring MVC）不会自动捕获这个异常——它一路冒泡到容器线程，最终变成未处理异常，触发默认错误页或空响应。你看到的“接口偶尔超时后直接挂掉”，大概率就是这个原因。
常见错误现象：java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@12345678 rejected from java.util.concurrent.ThreadPoolExecutor@87654321[Running, pool size = 10, active threads = 10, queued tasks = 100, completed tasks = 1234]
- 不是队列满了才拒绝，而是提交时线程池已 shutdown / 达到核心线程+队列上限，且无法扩容（
maximumPoolSize已满） -
AbortPolicy是默认策略，但生产环境几乎不该用 - 别指望靠“加大队列”解决根本问题——堆积的任务会吃光堆内存，GC 压力陡增
怎么写一个带日志和降级的自定义拒绝策略？
核心是实现 RejectedExecutionHandler 接口，重点不在“怎么写”，而在“拒绝时该做什么动作”。推荐组合式策略：记录上下文 + 同步降级 + 可选告警。
示例策略逻辑：
- 用
Logger记录被拒任务的类名、方法名（如果能拿到）、提交时间、当前活跃线程数、队列大小（通过executor.getQueue().size()） - 调用预设的降级方法（如返回缓存值、空对象、或 fallback API），注意：必须是同步、无副作用、不依赖线程池本身的逻辑
- 避免在拒绝策略里做耗时操作（如发 HTTP 请求、查 DB），否则会卡住
submit()调用方 - 可加简单计数器（如
AtomicInteger）统计 1 分钟内拒绝次数，超阈值触发一次告警（避免刷屏）
简短示例：
public class LoggingAndFallbackPolicy implements RejectedExecutionHandler {
private final Logger logger = LoggerFactory.getLogger(LoggingAndFallbackPolicy.class);
private final AtomicInteger recentRejects = new AtomicInteger();
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
int rejects = recentRejects.incrementAndGet();
if (rejects == 1 || rejects % 60 == 0) { // 每分钟最多告警一次
logger.warn("Task rejected: {}, active={} queue={} max={}",
r.getClass().getSimpleName(),
executor.getActiveCount(),
executor.getQueue().size(),
executor.getMaximumPoolSize());
}
// 同步降级：这里调用你的 fallback 方法，不要 new Thread 或 submit 到别的池
doFallback(r);
}
private void doFallback(Runnable r) {
// 实际业务逻辑，例如返回默认响应、打点上报、或什么都不做
}
}
CallerRunsPolicy 真的适合高并发场景吗？
不适合。它把任务丢回给调用线程执行，表面看“不丢任务”，实则把压力反向传导到上游——比如 HTTP 请求线程自己去跑本该异步处理的 DB 查询，导致请求响应时间飙升、连接池耗尽、甚至整个 Tomcat 线程池卡死。
- 适用场景仅限：低频、非关键、可容忍延迟毛刺的任务（如日志异步刷盘）
- 在 Spring Boot 中，如果你用
@Async配了线程池，又设成CallerRunsPolicy，那每个@Async方法调用都可能阻塞 Web 线程 - 性能影响显著：吞吐量可能下降 30%+，P99 延迟翻几倍，且问题难定位（没有明显异常，只有慢）
Spring Boot 里怎么替换默认拒绝策略？
不能只改 ThreadPoolTaskExecutor 的 setRejectedExecutionHandler()，因为 Spring 的自动配置会在你之前就初始化好 Bean。必须提前干预或覆盖 Bean。
- 最稳妥方式：自定义
@Bean，显式 new 一个ThreadPoolTaskExecutor，并 setHandler；同时用@Primary或调整@Order确保它被注入 - 别用
spring.task.execution.pool.*配置项——它只支持内置策略名（abort/caller-runs等），不支持自定义类 - 如果用的是
Executors.newFixedThreadPool()这类静态工厂，记得换成new ThreadPoolExecutor(...)构造，才能传入自定义 handler - 注意线程池 Bean 的作用域：Web 应用里通常应为 singleton，避免每次请求都新建池
