线程池最优规模是动态值，由任务类型、硬件能力与运行时状态共同决定；需区分CPU/IO密集型行为，混合任务应拆分池，结合监控指标动态调优，并配合适当队列与拒绝策略。

线程池最优规模不是固定数字，而是任务类型、硬件能力与运行时状态共同决定的动态值。IO密集型常用“2倍CPU核数”、CPU密集型用“核数+1”，只是经验起点，不能直接照搬。

区分任务类型是调整前提

判断依据不在代码写法，而在实际执行行为：

• CPU密集型：线程大部分时间在计算（如加解密、矩阵运算、JSON序列化），CPU使用率持续高于80%，等待时间极短或为零
• IO密集型：线程频繁阻塞于网络响应、磁盘读写、数据库返回等（如HTTP调用平均耗时300ms，而CPU处理仅5–20ms），CPU使用率常低于40%
• 混合型任务建议拆分线程池——IO操作走专用池，后续计算走CPU池，避免互相拖慢

硬件差异影响公式落地效果

同是8核机器，物理核数、是否开启超线程、内存带宽、网卡吞吐都会改变线程承载上限：

• 纯物理8核服务器：IO密集型初始可设为16～32，但若JVM堆外内存有限（如Netty直接内存仅512MB），或HTTP连接池上限为200，则线程数不应超过该瓶颈
• 16线程（8核+超线程）笔记本：理论可支撑更多并发，但散热与电源限制会导致频率降频，实测可能16线程即触发调度延迟，需压测验证
• 云环境（如AWS c6i.2xlarge）：vCPU共享物理资源，IO延迟波动大，应以监控指标（如activeCount持续接近maximumPoolSize且queueSize增长）为扩容信号，而非静态公式

动态调整比静态公式更可靠

公式给出的是上线前的参考值，真实最优值必须靠运行时反馈闭环校准：

• 关键监控指标：getActiveCount()（活跃线程）、getQueue().size()（待处理任务）、getCompletedTaskCount()（完成量趋势）、rejectedExecutionCount（拒绝数）
• 扩容条件：队列持续积压 + 活跃线程已达maximumPoolSize + 平均响应时间上升 → 调用setMaximumPoolSize()提升上限
• 缩容条件：活跃线程长期稳定在corePoolSize的60%以下 + 响应时间平稳 + 系统load average回落 → 逐步下调corePoolSize
• 建议接入Micrometer暴露指标，用Prometheus+Grafana配置告警：queueSize > 100 或 rejectedExecutionCount > 0 持续1分钟即触发人工介入

队列与拒绝策略决定线程数是否生效

再合理的线程数，配错队列和拒绝策略也会失效：

• SynchronousQueue：适合高吞吐、低延迟场景，新任务直接触发扩容，必须配合理maximumPoolSize和AbortPolicy，否则任务静默丢失
• LinkedBlockingQueue（尤其无界）：易掩盖容量问题，当IO变慢时，任务持续入队，最终OOM；建议设为有界（如100～500），配合CallerRunsPolicy让调用线程自己执行，自然限流
• 拒绝策略优先选AbortPolicy（抛异常），便于快速暴露线程池饱和问题；避免用DiscardPolicy或DiscardOldestPolicy，它们不报错却丢任务