线程池参数需按任务类型（cpu/io/混合型）差异化配置：cpu密集型设核心数或+1，io密集型设核心数×2～4；队列选synchronousqueue触发即时扩容，arrayblockingqueue控积压，禁用linkedblockingqueue；需结合内存、拒绝策略与监控动态调优。
核心线程数和最大线程数不能靠固定公式硬套，得看任务实际“忙什么”、系统“能扛多少”、业务“容不容错”。设小了压不住并发，设大了反而拖慢整体——关键在匹配，不在堆数字。
先分清任务是 CPU 忙还是 IO 等
这是所有配置的起点。同一套参数用在图像压缩和 HTTP 调用上，效果可能天差地别。
- CPU 密集型（如数值计算、JSON 序列化、加密解密）：线程基本不等待，CPU 利用率持续高位。核心线程数建议设为 CPU 核数 或 CPU 核数 + 1；最大线程数通常与核心数一致或略高（比如 +1～2），避免无效上下文切换和 cache miss。
- I/O 密集型（如数据库查询、RPC 调用、文件上传）：线程大量时间阻塞在 socket 或磁盘响应上。此时可利用空闲 CPU 并行更多线程，核心线程数常见设为 CPU 核数 × 2～4，最大线程数可放宽至 × 5～8，但必须配合有界队列防雪崩。
- 混合型任务（现实中大多数）：不要强行统一配置。优先拆分——把 DB 操作、缓存刷新、日志上报等不同延迟特征的任务路由到各自专用线程池，比塞进一个“万能池”更可控、易监控。
队列类型决定“扩不扩容”的逻辑
最大线程数是否真会被用到，取决于工作队列行为。线程池不会因为队列里有积压就立刻扩容，而是等队列满后才新建线程。
- SynchronousQueue（容量为 0）：任务无法入队，提交即触发扩容（只要未达 maximumPoolSize）。适合响应敏感、任务轻量的场景，例如网关转发。
- ArrayBlockingQueue（固定容量）：队列满才扩容。推荐用于希望明确控制内存占用与排队深度的业务，比如批量导入限制最多积压 1000 条。
- LinkedBlockingQueue（无界）：慎用！它会让 maximumPoolSize 形同虚设——所有超额任务都进队列，永不触发扩容，最终 OOM 风险极高。除非你 100% 确认吞吐恒定且总量可控。
结合硬件与稳定性做权衡
参数不是孤立存在的，要和内存、CPU、拒绝策略联动考虑。
- 每个线程默认栈空间约 1MB（可通过
-Xss调整），线程数过多容易触发OutOfMemoryError。可用线程数 ≈ 可用内存 ÷ 单线程栈大小。 - maximumPoolSize 建议 ≤ corePoolSize × 2（I/O 型可放宽至 × 4～5），防止系统资源（内存、文件句柄、上下文切换）被耗尽。
- keepAliveTime 只作用于非核心线程，设得太短会导致频繁创建销毁；太长则空闲资源释放慢。一般设为 60 秒较稳妥。
- 拒绝策略选哪种，反映你对稳定性的取舍：AbortPolicy 抛异常（适合强校验）、CallerRunsPolicy 让调用线程执行（降低吞吐保可用）、DiscardPolicy 直接丢弃（适合日志类低优任务）。
最后记得留出观测和调整空间
上线后务必监控活跃线程数、队列长度、拒绝任务数、平均处理时间等指标。如果发现队列长期积压、拒绝率突增或 CPU 使用率持续低于 60%，说明当前配置已不匹配实际负载，需要动态调优。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
