Java线程池核心参数需按任务类型与系统资源协同设计：corePoolSize设为CPU核数+1（CPU密集型）或×2～4（IO密集型）；maximumPoolSize应防过载，CPU型建议等于corePoolSize，IO型可适度放大；workQueue优先选有界ArrayBlockingQueue；keepAliveTime控制非核心线程存活时间，拒绝策略依业务语义选择。
Java 线程池的核心参数不是随便填的数字，而是要根据任务特性、系统资源和业务压力来协同设计。理解它们的关键，在于抓住“线程怎么来、任务往哪放、满了怎么办”这三条主线。
corePoolSize：常驻线程数，决定最低并发能力
这是线程池启动后就维持的最小线程数量，即使空闲也不销毁（除非开启 allowCoreThreadTimeOut）。它不是“建议值”，而是线程池响应新任务的第一道防线。
- CPU 密集型任务（如图像压缩、算法计算）：设为 CPU 核心数 + 1。+1 是为了应对偶尔的阻塞（如缺页、锁等待），避免 CPU 空转
- IO 密集型任务（如 HTTP 调用、数据库查询）：设为 CPU 核心数 × 2 ～ 4，因为线程大量时间在等待，需要更多线程“轮着等”来压满 CPU 利用率
- 混合型任务：可先设为 CPU 核心数 × 1.5，上线后结合监控（如
getActiveCount()、GC 频率）动态调优
maximumPoolSize：最大线程上限，防系统过载
它定义了线程池能创建的线程总数（核心 + 非核心），只有当工作队列已满且当前线程数未达此值时，才会新建非核心线程。它本质是资源保护阀。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 对 CPU 密集型：建议与
corePoolSize相同或最多 +2，避免上下文切换开销反超收益 - 对 IO 密集型：可设为
corePoolSize × 2或按峰值 QPS × 平均响应时间粗略估算，但必须结合服务器内存和文件句柄数限制（例如 4C8G 机器不宜超过 200 线程） - 重要原则：不要盲目设成
Integer.MAX_VALUE，否则高并发下极易触发 OOM 或 CPU 100%
workQueue：任务缓冲区，决定“排队还是扩容”
它不是越大越好，而是决定了线程池面对突发流量时的策略倾向——是优先缓存任务，还是优先扩容线程。
立即学习“Java免费学习笔记（深入）”；
- ArrayBlockingQueue（有界）：推荐首选。容量需明确指定（如 100～1000），能防止任务无限堆积导致内存溢出，配合合理拒绝策略更可控
- SynchronousQueue（无缓冲）：不保存任务，提交即尝试交给空闲线程；若无空闲，则立即触发扩容逻辑。适合任务处理快、希望快速感知压力的场景
-
LinkedBlockingQueue（默认无界）：慎用！默认容量是
Integer.MAX_VALUE，看似“永不拒绝”，实则可能把所有请求堆进内存，最终 OOM
keepAliveTime + unit 与 rejectedExecutionHandler：兜底机制
这两个参数共同构成线程池的“安全网”。
-
keepAliveTime控制非核心线程的存活时长（如 30～60 秒），避免临时线程长期闲置浪费资源 - 拒绝策略选型要匹配业务语义：
• AbortPolicy（默认）：抛异常，适合强一致、不可丢任务的场景
• CallerRunsPolicy：由提交任务的线程自己执行，可自然降级、缓解压力，适合后台异步日志等
• DiscardPolicy：静默丢弃，适用于实时性要求高、允许少量丢失的指标上报类任务
