根本原因是自定义拒绝策略存在无节制自旋循环，导致CPU单核满载；应立即切换为CallerRunsPolicy等安全策略，并在自研策略中加入重试限制、退避休眠和熔断机制。
这种情况本质是线程池拒绝策略被高频触发，而你选的策略（比如自定义的、或误用的 AbortPolicy 衍生实现）内部存在无条件循环或忙等待逻辑，且没有节流、休眠、计数或熔断机制，导致单个 CPU 核心被死死占满，温度骤升。
确认是否真是拒绝策略引发的死循环
先别急着调参，得定位源头：
- 查日志：搜索
RejectedExecutionException出现频次——如果每秒几十甚至上百次，说明拒绝已成常态； - 抓线程快照：
jstack -l <pid>看是否有线程长时间停留在你自定义拒绝策略的某一行（如while (true) { ... }或空循环 + 自旋判断）； - 对比监控：用
top -H -p <pid>找出占用率最高的 LWP（轻量级进程），再用jstack匹配其 nid（十六进制），确认它卡在拒绝逻辑里。
立即止损：替换为安全的拒绝策略
临时上线最稳妥的做法，是把有问题的自定义策略换成 JVM 内置的、行为明确的策略：
- CallerRunsPolicy：让提交任务的线程自己执行该任务。虽会拖慢调用方，但天然限流、不新增线程、不自旋，CPU 压力直接回落；
- DiscardOldestPolicy：丢掉队列里最老的任务，腾出位置。适合允许轻微丢失、但不能阻塞或自旋的场景；
- 绝对避免手写
while(!canAccept()) {}类型的“等可用”逻辑——没有超时、没有退避、没有 yield，就是物理核的杀手。
长期修复：拒绝策略必须带控速和兜底
如果你确实需要自定义策略（比如记录告警、降级处理），务必加入三重防护：
- 最大重试次数限制：比如最多尝试 3 次获取资源，之后强制丢弃或异步上报；
-
最小退避间隔：每次失败后
Thread.sleep(1)或LockSupport.parkNanos(1_000_000)，哪怕 1ms 也能打断密集自旋； -
全局熔断开关：配合 Sentinel 或自维护计数器，当 1 秒内拒绝超 100 次，自动切换为
DiscardPolicy，防止雪崩式自旋。
顺手检查线程池基础配置是否放大了问题
拒绝策略只是最后一道闸门，上游配置不合理会让它天天被撞开：
- 确认
corePoolSize不是远超 CPU 核数（例如 32 核机器设 64 核心线程），否则上下文切换本身就会抬高 CPU 温度； - 检查队列类型：千万别用
LinkedBlockingQueue(Integer.MAX_VALUE)，它会让拒绝永远不触发，转而压垮 GC 和内存； - 观察
maximumPoolSize是否过小——如果核心线程+队列早满，又不让开临时线程，拒绝就成了唯一出口，压力全堆到策略上。
