直接停掉问题线程池并替换为有界、可控的线程池是破局关键：冻结创建、强制回收、在线干预（shutdownNow或JVM attach），确认线程回落，根治选用固定大小+有界队列（CPU型用SynchronousQueue，IO型用LinkedBlockingQueue），辅以命名线程工厂、上下文切换监控（vmstat/pidstat/jstack）及长期防控（Prometheus监控、压测、CI门禁）。
直接停掉问题线程池并替换为有界、可控的线程池实现，是破局关键。高频无脑调用 CachedThreadPool 的本质，是把“自动扩容”当万能解药，却无视了它底层用的是 SynchronousQueue + 无上限线程创建——请求一涌而入，线程就疯长，CPU 不是花在干活上，全耗在切换上下文里。
立刻止损：冻结线程创建 + 强制回收空闲线程
无需重启应用，可在线干预：
- 调用
executor.shutdownNow()，向所有运行中线程发送中断信号，并清空任务队列（注意：未开始的任务会被丢弃） - 若无法修改代码，可通过 JVM attach 方式触发线程池关闭（需提前暴露管理端点，如 Spring Boot Actuator 的
/actuator/threaddump或自定义 JMX 操作） - 确认线程数回落：执行
top -H -p <java_pid></java_pid>，观察线程总数是否明显下降；再用ps -T -p <java_pid> | wc -l</java_pid>统计当前线程数
根治替换：用固定大小 + 有界队列的线程池替代
CachedThreadPool 适合短时突发、任务极轻量（如纯内存计算）、且总量可控的场景。生产环境绝大多数 I/O 密集型任务（HTTP 调用、DB 查询、文件读写）都不适用它。应换成：
-
CPU 密集型任务：核心线程数设为
Runtime.getRuntime().availableProcessors() + 1，队列用SynchronousQueue，拒绝策略选AbortPolicy -
I/O 密集型任务：核心线程数建议
cpuCount × 2 ~ 4，队列用LinkedBlockingQueue(1024)（必须有界），拒绝策略用CallerRunsPolicy（让调用方自己执行，自然限流） - 务必显式命名线程工厂，例如
new NamedThreadFactory("order-processor")，便于后续通过jstack快速识别线程归属
定位与验证：确认是否真由上下文切换引发
别只看 CPU 百分比，要查证据：
- 运行
vmstat 1，重点关注cs（context switch）列：持续 > 50000/秒 就属异常高，>100000 基本可断定是线程风暴 - 执行
pidstat -w -p <java_pid> 1</java_pid>，观察cswch/s（每秒任务切换）和nvcswch/s（每秒非自愿切换）：后者飙升说明线程频繁被抢占，正是CachedThreadPool疯狂创建导致的典型表现 - 用
jstack <pid></pid>抓堆栈，搜索RUNNABLE状态线程——如果上百个线程都卡在Unsafe.park、Object.wait或刚进入run()就没下文，基本就是线程创建泛滥、调度器不堪重负
长期防控：加监控 + 压测 + 代码门禁
防止同类问题复发，得靠机制：
- 在 Prometheus + Grafana 中接入线程池指标：活跃线程数、队列长度、拒绝任务数（用
ThreadPoolExecutor的getActiveCount()、getQueue().size()、自定义拒绝策略计数器） - 所有新上线的异步任务，必须经过压测：模拟 3~5 倍日常峰值流量，观察线程数增长曲线和
cs值是否陡升 - 在 CI 流程中加入静态扫描规则，禁止代码中出现
Executors.newCachedThreadPool()，强制使用公司封装的SafeThreadPoolBuilder类
