线程池大小存在临界点，过小导致任务积压、延迟飙升，过大引发资源争抢、上下文切换激增；需匹配真实并发压力，并协同约束数据库连接、外部服务限流等瓶颈。
线程池大小与系统负载不是简单的正比关系，而是存在一个“临界点”：过小会压垮响应能力，过大反而加剧系统负载。关键在于让线程数匹配真实并发压力，而非盲目堆数量。
线程池太小 → 负载表现为“隐性积压”
当 corePoolSize 或 maximumPoolSize 设置过低（例如固定为 2～4），即使 CPU 有多核空闲，大量任务也只能排队等待。尤其在 I/O 密集型场景中，线程常处于 WAITING 状态，但线程池不扩容，新任务持续涌入 workQueue —— 队列不断增长、响应延迟飙升、拒绝策略频繁触发。
- 典型信号：ThreadPoolExecutor.getQueue().size() 持续上升，getActiveCount() 长期低于 corePoolSize
- 后果：请求吞吐量下降、P99 延迟陡增、下游服务因超时被连带拖慢
- 常见误配：用 newFixedThreadPool(2) 处理 Web API，或未设 maximumPoolSize 的自定义 ThreadPoolExecutor
线程池太大 → 负载表现为“显性资源争抢”
线程数远超系统承载能力（如设为 500+）会直接抬高系统负载：
- 每个线程默认占用约 1MB 栈空间（-Xss 可调但不推荐过小），易触发 OutOfMemoryError: unable to create new native thread
- 操作系统频繁调度数百线程，上下文切换开销剧增，CPU 使用率虚高但有效计算下降
- 内存带宽、GC 压力同步上升，可能引发 Full GC 频繁或 STW 时间延长
特别注意：Executors.newCachedThreadPool() 因无 maximumPoolSize 限制，在流量突增时极易失控创建数千线程，应避免在生产环境使用。
负载均衡的关键不在“线程数”，而在“协同约束”
真正影响系统负载的，不只是线程池本身，还包括它所依赖的上下游资源瓶颈。若忽略这些，调大线程池只会把压力转嫁出去：
- 数据库连接池：若 HikariCP 最大连接数为 50，而线程池设为 200，那 150 个线程将长期阻塞在 getConnection() 上，形成无效等待
- 外部服务限流：调用 QPS 上限为 20 的第三方接口，线程池设为 100 就毫无意义，多数线程只能排队等令牌
- 磁盘/网络带宽：批量文件写入场景下，线程再多也受限于 I/O 吞吐，反而加剧 seek 和锁竞争
建议做法：线程池大小 ≤ min(CPU核心数 × 扩容系数, 数据库最大连接数, 外部服务并发上限)。
动态观察比静态配置更可靠
系统负载是实时变化的，靠公式估算不如靠指标驱动：
- 监控核心指标：活跃线程数（getActiveCount）、队列长度（getQueue().size()）、拒绝任务数（getRejectedExecutionCount）、CPU 利用率、GC 时间
- 压测验证：用 JMeter 或 wrk 模拟不同并发等级，观察响应时间拐点和错误率突增点
- 谨慎动态调整：虽可通过 setCorePoolSize() 修改，但仅适合稳态可预测的负载波动；突发流量更应依赖有界队列 + 合理拒绝策略，而非临时扩线程
本质上，线程池不是性能加速器，而是负载调节阀——调得准，系统平稳；调不准，问题只是换了个地方爆发。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
