threadpoolexecutor 的行为由七个核心参数决定，其中 corepoolsize 是长期维持的最小线程数，cpu 密集型任务建议设为 cpu 核数，io 密集型任务可设为 2 倍或更高。

ThreadPoolExecutor 是 Java 并发编程中最关键的线程池实现，它的行为完全由七个核心参数决定。参数配得准不准，直接关系到系统吞吐、响应延迟和稳定性。不是堆大数字就高效，也不是照搬模板就安全。

corePoolSize：核心线程数，线程池的“常备军”

这是线程池长期维持的最小线程数量。只要没设置 allowCoreThreadTimeOut = true，这些线程哪怕空闲也不会被回收。

• CPU 密集型任务（如图像处理、复杂计算）：通常设为 Runtime.getRuntime().availableProcessors()
• IO 密集型任务（如数据库查询、HTTP 调用）：可设为 2 倍 CPU 核数，甚至更高，因为线程常在等待
• 提交新任务时，若当前线程数
• 可通过 setCorePoolSize() 动态调整，调小后多余线程会在下次空闲时退出

maximumPoolSize：最大线程数，系统的“应急上限”

当任务持续涌入、队列已满且核心线程全忙时，线程池会扩容创建非核心线程，直到达到这个值。超过它，新任务就会触发拒绝策略。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 不能盲目设为 Integer.MAX_VALUE —— 容易引发 OOM 或上下文切换风暴
• 合理估算公式：(峰值 QPS × 平均任务耗时) ÷ 可接受最大响应时间，例如 QPS=500、平均耗时 200ms、目标 RT≤500ms → 500×0.2/0.5 = 200
• 常见经验范围是 corePoolSize 的 2–4 倍，但必须结合监控数据验证（比如 rejected count、pool size peak）
• 同样支持运行时调用 setMaximumPoolSize() 动态修改

workQueue + keepAliveTime + unit：协同决定“何时扩容”与“何时缩容”

这三个参数共同构成线程池的弹性伸缩逻辑。队列类型选错，keepAliveTime 再合理也白搭。

• ArrayBlockingQueue（有界）：推荐用于可控场景，能防止任务无限堆积；容量需结合吞吐与内存权衡
• LinkedBlockingQueue（默认无界）：看似省心，实则容易掩盖问题——任务积压不触发扩容，最终拖垮内存
• SynchronousQueue（同步移交）：不存储任务，直接交由空闲线程或触发扩容，适合高并发短任务
• keepAliveTime 只对超出 corePoolSize 的非核心线程生效；单位建议用 TimeUnit.SECONDS，避免纳秒级误配

threadFactory 与 handler：让线程池真正“可运维”

这两个参数常被忽略，却是定位问题和保障稳定的关键。

• 自定义 ThreadFactory 至少应设置有意义的线程名（如 “order-processor-1”），便于日志追踪和 JStack 分析
• 拒绝策略不能只用默认的 AbortPolicy（抛异常中断业务），生产环境推荐：
  → CallerRunsPolicy：由调用方降级执行，缓解压力
  → DiscardOldestPolicy：丢弃队列最老任务，保留最新请求（适用于时效敏感场景）
• handler 需配合监控告警，一旦触发，说明线程池已饱和，必须排查是突发流量、慢 SQL 还是配置失当

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南