核心线程数与最大线程数需依任务类型、硬件资源及稳定性目标动态设定：cpu密集型设为cpu核心数或+1，io密集型设为cpu核心数×2～4（最大可达×6～8），混合型宜拆分专用线程池并结合监控调优。
核心线程数和最大线程数不是靠经验数字堆出来的，而是任务特性、硬件资源与稳定性目标共同约束下的结果。设得小了压不住并发，设得大了反而拖垮系统——关键在“匹配”，不在“最大”。
先分清任务是CPU忙还是IO等
这是所有设置的起点。同一套参数用在加密计算和HTTP调用上，效果可能天差地别。
- CPU密集型：比如图像缩放、数值模拟、JSON序列化-heavy场景。线程基本不等待，CPU利用率持续高位。这类任务的核心线程数建议设为 CPU核心数 或 CPU核心数 + 1；最大线程数通常与核心数一致，避免无效上下文切换。
- IO密集型：比如数据库查询、RPC调用、文件上传下载。线程大量时间阻塞在socket读写或磁盘响应上。此时可利用空闲CPU并行更多线程，常见做法是设核心线程数为 CPU核心数 × 2～4，最大线程数再往上放宽（如 × 6～8），但必须配合有界队列防雪崩。
- 混合型任务：现实中多数属于此类。不要强行统一配置，优先考虑拆分——把DB操作、缓存刷新、日志上报等不同延迟特征的任务路由到各自专用线程池，比塞进一个“万能池”更可控、易监控。
队列类型决定“扩不扩容”的逻辑
最大线程数是否真会被用到，取决于工作队列行为。线程池不会因为队列里有积压就立刻扩容，而是等队列满后才新建线程——这个“满”的定义由队列类型决定。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- SynchronousQueue：容量为0，任务无法入队，提交即触发扩容（只要未达maximumPoolSize）。适合响应敏感、任务轻量的场景，例如网关转发。
- ArrayBlockingQueue：固定容量，队列满才扩容。推荐用于希望明确控制内存占用与排队深度的业务，比如批量导入任务限制最多积压1000条。
- LinkedBlockingQueue（无界）：慎用！它会让maximumPoolSize形同虚设——所有超额任务都进队列，永不触发扩容，最终OOM风险极高。除非你100%确认吞吐恒定且总量可控。
拒绝策略是最后的安全阀
当队列已满、线程已达maximumPoolSize，新任务就必须被拒绝。选哪种策略，反映你对稳定性的取舍。
- AbortPolicy（默认）：直接抛异常。适合不允许丢任务、且上游能重试的场景，比如支付回调处理。
- CallerRunsPolicy：让提交任务的线程自己执行。会降低吞吐但保住了数据不丢，也反向抑制上游提交速度，适合突发流量削峰。
- DiscardPolicy：静默丢弃。适用于日志采集、监控埋点等允许丢失的非关键路径。
上线后必须靠监控迭代调优
公式只是起点，真实负载下线程池的表现需要数据验证。重点关注三项指标：
- 活跃线程数长期接近corePoolSize？说明当前配置够用，甚至可适度下调。
- 队列持续积压、活跃线程频繁触达maximumPoolSize？说明核心数偏低或任务耗时突增，需检查慢SQL或外部依赖超时。
- 拒绝任务数上升？不是立刻加线程，先看是偶发高峰还是常态——后者更可能是下游瓶颈或代码阻塞，加线程只会掩盖问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
