拒绝策略在队列已满且活跃线程数达maximumpoolsize时触发，或线程池处于shutdown/stop状态时立即触发；默认abortpolicy易引发雪崩，callerrunspolicy可能阻塞io线程。
线程池拒绝策略到底在什么情况下触发
不是“线程数满了就拒绝”，而是当 任务提交量 > corePoolSize + queueCapacity + (maximumPoolSize - corePoolSize) 时才真正触发——更直白说，是“队列已满 且 当前活跃线程数已达 maximumPoolSize”的瞬间。
常见错误现象：用 Executors.newFixedThreadPool(5) 测试拒绝策略却始终不触发，因为它的 LinkedBlockingQueue 默认无界（容量为 Integer.MAX_VALUE），永远填不满。
- 必须显式使用有界队列，比如
new ArrayBlockingQueue(10) - 确保
corePoolSize和maximumPoolSize相等（如都设为 2），否则队列满后还会继续扩容线程，延迟触发时机 - 线程池处于
SHUTDOWN或STOP状态时，任何新任务都会立即触发拒绝策略，与队列/线程数无关
AbortPolicy 是默认策略，但抛异常不等于“安全”
它直接抛出 RejectedExecutionException，看起来很“明确”，但实际线上容易引发雪崩：上游调用方若没做 try-catch，可能整个请求链路直接 500；日志里只看到 “Task xxx rejected from …”，没有上下文、无业务标识、难定位哪类任务被拒。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 别依赖默认策略做流量兜底，尤其在网关、支付等关键路径
- 若真要用
AbortPolicy，务必配合监控告警（比如捕获该异常并上报 Prometheus 的threadpool_reject_count指标） - 测试时注意：异常发生在
execute()调用栈里，不是在任务run()中，所以submit().get()才能拿到异常，execute()会直接炸掉主线程
CallerRunsPolicy 看似温和，实则暗藏阻塞风险
它让提交任务的线程（比如 Tomcat 的 http-nio-8080-exec-23）自己去执行被拒任务，相当于把压力“反射”回上游。好处是天然限流，坏处是可能卡住 IO 线程，导致后续请求堆积。
- 仅适合任务执行时间极短（
- 绝对不能用于 Web 容器线程池（如 Tomcat）的下游线程池，否则一个慢任务就能拖垮整个 HTTP 线程池
- 如果任务本身含同步 IO（如 DB 查询），
CallerRunsPolicy可能引发线程饥饿，表现为你发现 CPU 不高但 QPS 断崖下跌
DiscardOldestPolicy 和 DiscardPolicy 都是“丢”，但丢法不同
DiscardPolicy 是静默丢弃最新任务；DiscardOldestPolicy 则先踢掉队列头那个最老任务，再把当前任务塞进去——看似“腾位置”，实则破坏 FIFO 语义，老任务反而比新任务更可能丢失。
- 两者都不记录日志，生产环境基本不可用，除非你明确知道丢的是心跳、埋点等无状态低优先级任务
-
DiscardOldestPolicy在高并发下有竞态风险：e.getQueue().poll()和e.execute(r)非原子，中间若有其他线程插入，可能导致重复丢弃或队列溢出 - 真要丢，建议自定义策略，至少打一条带 traceId 和任务类型的关键日志，比如：
log.warn("DISCARD_TASK type=order_timeout traceId={}", traceId)
最容易被忽略的一点：拒绝策略只处理“提交阶段”的任务，对已入队但长期未执行的任务（比如队列积压 5 分钟），策略完全不生效——那是你队列容量和线程吞吐量设计失衡的问题，得从监控队列水位、设置任务超时、拆分大任务入手，而不是指望拒绝策略兜底。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
