线程池参数是上下文切换的“开关”，需按CPU核心数与任务类型精准配置：CPU密集型设为核数+1，IO密集型按公式估算且≤200；禁用无界队列和CachedThreadPool；maximumPoolSize应略高于峰值并发，避免调度风暴；优先使用ForkJoinPool+CompletableFuture实现动态负载均衡。
线程池参数不是配置项，而是上下文切换的“开关”。调得准，线程各司其职、CPU饱满运行；调得松，大量线程在就绪队列里排队、争锁、被调度器反复挂起和唤醒，切换开销直接吃掉有效计算时间。
corePoolSize 超过 CPU 核心数会指数级抬高切换频率
这不是理论预警，是压测可复现的现象：在 4 核服务器上跑纯计算任务，corePoolSize 从 4 增至 8，每秒上下文切换从 1300 次飙升到 9800 次；增至 16 时突破 2.8 万次。原因很直接——超出物理并发能力的线程只能靠时间片轮转，频繁保存/恢复寄存器、刷新 TLB、失效缓存行。一次切换耗时 1–5 微秒，百万级切换就是整颗 CPU 在“空转”。
- CPU 密集型任务：设为 CPU 核心数 + 1（+1 应对页缺失等瞬时停顿）
- I/O 密集型任务：按公式 CPU 核心数 × (1 + 平均等待时间 / 平均工作时间) 估算，但上限建议 ≤ 200
- 绝对避免用
Executors.newCachedThreadPool()——它无上限创建线程，突发流量下切换成本爆炸
workQueue 容量过大反而加剧线程调度压力
队列不是“缓冲区”，它是延迟和内存风险的放大器。大容量队列让任务堆积而不拒绝，线程看似“闲着”，实则长期处于就绪态等待调度，内核持续做无效上下文切换。更糟的是，队列中待命任务越多，线程竞争越激烈，锁争抢导致更多线程被挂起。
- 用有界队列（如
ArrayBlockingQueue），容量按峰值 QPS × 平均处理时间预估，留 20% 缓冲 - 禁用
LinkedBlockingQueue无界构造（new LinkedBlockingQueue()</code>），它等价于 <code>Integer.MAX_VALUE，突发流量下 GC 频繁、服务失稳 - 队列满时触发拒绝策略（如
AbortPolicy或自定义降级），把不可控的延迟转化为可观测、可告警的拒绝事件
maximumPoolSize 存在拒绝率陡升的临界点
最大线程数不是“兜底保险”，而是切换风暴的引爆点。当负载逼近 maximumPoolSize，线程创建/销毁、任务窃取、锁竞争全部集中爆发。实测显示，超过某阈值后，拒绝率会非线性跳升——不是因为资源不够，而是调度器已不堪重负。
立即学习“Java免费学习笔记（深入）”；
- 设为略高于业务峰值并发需求即可，例如：峰值 QPS 1200，平均响应 80ms → 理论并发 ≈ 1200 × 0.08 = 96，
maximumPoolSize设 120 已足够 - 不要简单设为
Integer.MAX_VALUE或远超硬件能力的数值（如 1000+） - 配合监控观察
getActiveCount()和getPoolSize()，若长期接近maximumPoolSize，说明要么任务太慢、要么线程池设计失当，而非“该扩容”
用 ForkJoinPool + CompletableFuture 替代传统线程池
普通线程池的静态分配难以应对动态负载，而 ForkJoinPool 的工作窃取机制天然减少空转和切换：空闲线程主动拉任务，避免排队等待；CompletableFuture 的链式异步组合把串行阻塞转为流水线执行，大幅降低线程挂起概率。
- 计算型任务优先走
ForkJoinPool，默认并行度为availableProcessors() - 1，不建议盲目调大 - IO 操作必须指定独立线程池：
thenApplyAsync(fn, ioExecutor)，绝不混入 commonPool - 禁止在
compute()或回调中写Thread.sleep()、JDBC 查询等阻塞逻辑，否则整个 worker 线程卡死，窃取机制失效
