核心线程数需依CPU核数与任务类型设定：CPU密集型≈核数+1，I/O密集型≈核数×2～4，混合型应拆分独立线程池；配套需启用超时回收、合理拒绝策略及命名线程工厂。
核心线程数（corePoolSize）不是随便填的数字，它直接决定线程池常驻线程规模，必须紧扣 CPU 核数和任务类型来定。配高了浪费资源、引发上下文切换；配低了压不住负载、CPU 利用率上不去。
CPU 密集型任务：核心线程数 ≈ CPU 核数 + 1
这类任务几乎不等待，全程占满 CPU（如图像压缩、数值计算、JSON 序列化）。此时线程数超过可用核心，只会让操作系统频繁调度，降低吞吐。
- 推荐值：
Runtime.getRuntime().availableProcessors() + 1 - 理由：+1 是为应对偶尔的页缺失或轻量 I/O，保证 CPU 始终有活可干
- 最大线程数通常与核心线程数一致或略高（如 +2～4），避免动态扩容带来的开销
- 队列建议用
ArrayBlockingQueue（小容量有界队列，例如 32～100），防止任务积压掩盖真实瓶颈
I/O 密集型任务：核心线程数 = CPU 核数 × 2～4（甚至更高）
这类任务大量时间花在等待（如 HTTP 调用、数据库查询、文件读写），CPU 实际使用率很低。多开线程能让 CPU 在等待间隙处理其他请求，提升整体吞吐。
- 经验起点：从
availableProcessors() * 2开始试，再根据实际表现调整 - 更精细公式：
cpuCores × (1 + 平均等待时间 / 平均计算时间)，例如等待占比 80%，可设为 ×5 - 队列宜选
LinkedBlockingQueue（容量建议 100～2000，视 QPS 和平均耗时估算） - 最大线程数可设为
corePoolSize × 2或更高，留出弹性空间应对突发延迟
混合型任务：拆分线程池，别硬凑一个
现实业务里，一个服务往往同时含计算逻辑和远程调用。强行共用线程池会导致慢 I/O 拖垮快计算，或 CPU 型任务抢占全部线程。
立即学习“Java免费学习笔记（深入）”；
- 最佳做法：为 CPU 型、I/O 型、定时任务分别建独立线程池
- 每个池按对应类型单独配置
corePoolSize、队列和拒绝策略 - 若暂时无法拆分，需通过压测 + 监控（如
getActiveCount()、getQueue().size()）反复调优，不能依赖理论公式
几个容易忽略的关键细节
光设对 corePoolSize 不够，配套动作同样重要：
- 启用
allowCoreThreadTimeOut(true)可让核心线程在空闲时也回收（适合流量波动大的场景） - 务必搭配合理拒绝策略（如
CallerRunsPolicy防止雪崩，AbortPolicy快速失败） - 线程工厂要设有意义的名称（如
"io-pool-%d"），方便日志排查和监控定位 - 不要用
Executors.newCachedThreadPool()——核心线程数为 0，最大为Integer.MAX_VALUE，极易失控
