核心线程数需按任务类型动态设定：CPU密集型设为CPU核数+1，I/O密集型设为核数×2～4，混合任务应拆分专用线程池，并结合activeCount、队列积压等监控持续调优。
核心线程数（corePoolSize）不是拍脑袋定的数字，而是要匹配任务特性、系统资源和实际负载。设小了会排队积压、响应变慢；设大了则空转耗内存、上下文切换反拖慢吞吐。
看任务类型定基准值
任务是 CPU 密集型还是 I/O 密集型，直接决定线程数的量级：
- CPU 密集型（如图像计算、加解密、复杂算法）：线程数 ≈ CPU 核心数 + 1。再多线程只会争抢 CPU，引发频繁切换，反而降低效率。
- I/O 密集型（如数据库查询、HTTP 调用、文件读写）：线程数可设为 CPU 核心数 × 2～4。因为线程常在等待响应，需要更多线程“轮着上”，才能填满 CPU 空闲时间。
结合平均活跃线程数校准
理论公式只是起点，真实业务中更可靠的是观察“常态下持续活跃的线程数量”：
- Web 请求处理：常见 4～8（取决于单次请求 I/O 占比）
- 数据库操作线程池：常设 10～20（需与 DB 连接池容量对齐）
- 消息消费（如 Kafka）：按分区数或下游处理能力微调，通常不低于 4
可通过 executor.getActiveCount() 和监控埋点长期统计，让 corePoolSize 覆盖 80%～90% 的日常峰值活跃线程数，而非极端瞬时高峰。
立即学习“Java免费学习笔记（深入）”；
注意队列行为对 corePoolSize 的隐性影响
corePoolSize 的效果高度依赖 workQueue 类型：
- 用 SynchronousQueue：不缓存任务，新任务必须立刻有空闲线程，此时 corePoolSize 就是“最小可用并发能力”，建议略高于平均并发，避免频繁触发拒绝。
- 用 LinkedBlockingQueue（无界）：任务全进队列，线程数永远卡在 corePoolSize，maximumPoolSize 失效——这时 corePoolSize 实际承担了“全部并发压力”，不宜过小，但更要警惕 OOM 风险。
- 用 ArrayBlockingQueue（有界）：队列满才扩容，corePoolSize 可设得保守些，靠队列缓冲日常波动，maximumPoolSize 应对短时尖峰。
避免几个典型误区
这些配置看似合理，实则隐患明显：
-
corePoolSize = 0：提交任务时无默认线程可用，除非调用
prestartAllCoreThreads()或队列已满触发扩容，否则任务直接卡住或被拒。 - corePoolSize = maximumPoolSize：等效固定线程池，失去弹性，突发流量无法缓冲，但适合极稳定、低延迟要求高的场景（如实时风控）。
- 盲目套用“2×CPU”万能公式：未区分任务阻塞比例，也未考虑下游资源瓶颈（如 DB 连接池只有 10，你开 50 个线程也没用）。
