CPU使用率100%时，线程池非根源而是负载、逻辑或资源配置失衡的表象；降级需“限制+分流+止损”，包括关闭非核心任务、拒绝新任务快速失败、暂停定时任务、优化单任务CPU消耗、动态调优线程池及前置防御措施。
CPU使用率100%时，线程池本身不是根源，而是任务负载、代码逻辑或资源配置失衡的表象。快速降级的核心是“限制+分流+止损”，而非单纯调小线程数。
立即生效的资源熔断措施
不等待JVM GC或系统调度，直接干预执行链路：
-
关闭非核心任务提交：用AtomicBoolean控制任务入口，如
if (!canAcceptTask.get()) return;，配合运维开关实时生效 -
拒绝新任务并快速失败：将线程池的
RejectedExecutionHandler设为AbortPolicy或自定义策略，抛出明确异常（如ServiceDegradedException），避免堆积 -
暂停定时/周期任务：若使用
ScheduledThreadPoolExecutor，调用shutdownNow()并清空getScheduledQueue()中待执行任务
针对性降低单任务CPU消耗
很多100% CPU源于单个任务内循环、正则回溯、序列化/反序列化或无界集合操作：
- 在耗时方法中插入
Thread.yield()或短时Thread.sleep(1)（仅用于紧急缓解，非长期方案） - 检查正则表达式是否含灾难性回溯（如
.*嵌套），改用确定性匹配或加超时（Pattern.compile(..., Pattern.CANON_EQ)不解决此问题，需重写逻辑） - 替换JSON库的默认解析器（如Jackson默认用树模型易占CPU），改用流式API（
JsonParser）处理大文本
动态调整线程池水位
静态配置无法应对突增流量，需运行时反馈调节：
立即学习“Java免费学习笔记（深入）”；
- 基于
ManagementFactory.getThreadMXBean().getThreadCpuTime(id)采样TOP N线程，识别热点任务类，临时将其所属线程池setCorePoolSize(1)和setMaxPoolSize(1) - 用Micrometer或自定义指标监控
pool.getActiveThreads()与system.cpu.usage联动，当CPU > 90%持续10秒，自动触发executor.setCorePoolSize(Math.max(2, current/2)) - 对IO密集型任务，显式分离线程池——绝不与CPU密集型任务共用同一池，避免相互拖慢
前置防御：上线前必须做的三件事
降级是救火，预防才是关键：
- 所有外部HTTP/API调用强制设置超时（连接+读取），用
OkHttpClient或RestTemplate配setConnectTimeout，防止线程卡死 - 业务关键路径加分布式信号量（如Redisson的
RSemaphore），限制并发数，比线程池限流更贴近业务语义 - JVM启动加
-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary，配合jcmd <pid> VM.native_memory summary排查堆外内存泄漏导致的CPU飙升
