Java线程池调度策略通过线程生命周期、队列行为与拒绝机制决定CPU负载：SynchronousQueue促响应但易线程爆炸，LinkedBlockingQueue致GC飙升，ArrayBlockingQueue助稳定；CPU密集型宜设线程数≈核数，IO密集型可2–4倍核数；拒绝策略是调度信号而非兜底；keepAliveTime影响弹性收缩，10–30秒更优。
Java线程池的任务调度策略直接影响CPU是否“忙得过来”还是“闲得发慌”。它不单是让任务排队或分发那么简单，而是通过线程生命周期管理、队列行为、拒绝时机等机制，决定CPU资源被抢占、等待、空转还是过载。调度策略选错，轻则CPU长期卡在20%，重则瞬间飙到100%并持续卡死。
任务队列类型决定CPU“呼吸节奏”
队列不是被动容器，它参与调度决策，左右线程创建与阻塞行为：
- SynchronousQueue：无缓冲，提交任务必须立刻有空闲线程接住，否则触发扩容（新建线程）或拒绝。适合高响应要求场景，能避免任务积压，但若maximumPoolSize设得大，易引发线程爆炸和频繁上下文切换，CPU利用率波动剧烈。
- LinkedBlockingQueue（无界）：任务来了全收，永不拒绝——看似友好，实则危险。当处理速度跟不上提交速度，任务在堆内存中越堆越多，触发频繁GC，CPU大量消耗在垃圾回收上，JStat显示GC时间占比常超60%，真实计算能力反而被拖垮。
- ArrayBlockingQueue（有界）：容量可控，配合合理拒绝策略（如AbortPolicy），能快速暴露系统瓶颈。任务积满即拒，倒逼上游限流或降级，CPU负载更平稳，利于容量规划和故障隔离。
核心线程数与CPU密集度强相关
线程数不是越多越好，关键看任务“吃CPU”还是“等IO”：
- CPU密集型任务（如加解密、数值计算）：线程数 ≈ Runtime.getRuntime().availableProcessors()。多于核数只会增加上下文切换开销，CPU使用率不升反降，还可能因争抢缓存导致L3命中率下跌。
- IO密集型任务（如HTTP调用、DB查询）：线程数可设为 CPU核数 × (1 + 平均等待时间 / 平均计算时间)。实践中常取 2–4 倍核数，让CPU在等待间隙继续处理其他任务，把“空等”时间转化为有效吞吐，提升整体利用率。
拒绝策略不是兜底，而是调度信号
拒绝不是失败，而是调度器向系统发出的“我撑不住了”的明确反馈：
立即学习“Java免费学习笔记（深入）”；
- CallerRunsPolicy：让提交线程自己执行任务。若主线程（如Tomcat的Acceptor）被拉去干重活，会直接拖慢新请求接入，形成雪崩前兆，CPU可能集中在少数线程上狂转，其余线程闲置。
- AbortPolicy（默认）：抛异常。配合监控告警，可及时发现流量突增或下游变慢，推动限流/熔断介入，避免CPU被无效排队耗尽。
- 自定义拒绝逻辑（如记录日志+降级返回）：把拒绝变成可观测事件，帮助反推调度策略是否匹配实际负载曲线。
keepAliveTime 控制弹性收缩灵敏度
这个参数决定了线程池“退潮”有多快，影响突发流量后的CPU回落效率：
- 设为60秒：高峰期创建的临时线程要等一分钟才释放，期间即使负载已下降，多余线程仍占着CPU调度名额，造成资源滞留。
- 设为10–30秒：实测中空闲线程平均存活时长下降76%，线程数从峰值232快速回落至稳定态48仅需23秒，内存回收提速2倍，CPU能更快回归健康水位。
