Java并发编程中的线程池参数调优_技术教程

corePoolSize应按CPU核心数×(1+I/O等待时间/CPU计算时间)设定，纯计算型设为availableProcessors()，I/O密集型可放大2–4倍；maximumPoolSize仅在ArrayBlockingQueue或SynchronousQueue下有效，配无界队列时无效且易OOM。

corePoolSize 和 maximumPoolSize 怎么设才不踩坑

线程池参数调优的核心矛盾，往往就卡在这两个值上。设小了，任务排队或拒绝；设大了，CPU 过载、上下文切换飙升，吞吐反而下降。

关键判断依据不是“有多少并发请求”，而是任务类型和系统资源：

corePoolSize 应接近 CPU 核心数 ×（1 + 平均 I/O 等待时间 / 平均 CPU 计算时间）——对纯计算型任务，可设为 Runtime.getRuntime().availableProcessors()；对大量数据库/HTTP 调用的任务，可放大到 2–4 倍
maximumPoolSize 在使用 LinkedBlockingQueue 时实际无效（因为队列无界，永远不触发扩容）；只有配 ArrayBlockingQueue 或 SynchronousQueue 时才有意义
线上常见错误：把 maximumPoolSize 设成 Integer.MAX_VALUE，又用无界队列，等于放弃线程数控制，OOM 风险陡增

keepAliveTime 设太短或太长分别会怎样

keepAliveTime 控制空闲线程的存活时长，直接影响线程复用效率和资源占用。

默认单位是秒，但很多开发者没注意单位参数传错，导致线程几毫秒就销毁，或几小时不回收：

设为 0L（配合 allowCoreThreadTimeOut(true)）：所有线程空闲即回收，适合流量波峰波谷明显的场景，但每次新请求都要重建线程，开销大
设为 60L（单位 TimeUnit.SECONDS）：较稳妥，兼顾响应与资源释放
设为 60L 但单位误传 TimeUnit.MILLISECONDS：线程 60 毫秒后全灭，等效于没用线程池

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4, 8,
    60L, TimeUnit.SECONDS, // 注意这里单位必须匹配
    new ArrayBlockingQueue<>(100),
    new ThreadFactoryBuilder().setNameFormat("biz-%d").build()
);

用什么阻塞队列？LinkedBlockingQueue 不一定最好

队列选型直接决定线程池行为模式：corePoolSiz

e 是否被尊重、maximumPoolSize 是否生效、拒绝策略何时触发。

三种常用队列的实际效果差异明显：

LinkedBlockingQueue（无界）：任务来者不拒，maximumPoolSize 形同虚设；内存压力随请求堆积线性上升；适合任务处理极快、且能确保不会持续积压的场景
ArrayBlockingQueue（有界）：队列满才创建新线程至 maximumPoolSize，之后触发拒绝策略；推荐容量设为预估峰值 QPS × 平均处理时长（秒），例如 100 QPS × 0.5s ≈ 50
SynchronousQueue（不存储）：每个任务必须立刻交给空闲线程，否则立即触发扩容或拒绝；适合高吞吐、低延迟、线程数可控的场景，但对突发流量零缓冲

拒绝策略不是摆设，要和监控联动

默认的 AbortPolicy 直接抛 RejectedExecutionException，但生产环境不能只靠异常日志被动发现瓶颈。

真正有效的做法是把拒绝当成信号，驱动容量决策：

用 CallerRunsPolicy 临时缓解：让提交线程自己执行任务，降低提交速率，适合非关键路径
自定义拒绝策略，记录指标（如 Prometheus Counter）并触发告警：rejected_task_total{pool="order"} 1
避免重试逻辑写在拒绝策略里——它在任务提交线程中执行，可能造成主线程阻塞或重复提交

new ThreadPoolExecutor(
    4, 8,
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(50),
    r -> new Thread(r, "order-worker-" + counter.getAndIncrement()),
    (r, executor) -> {
        Metrics.counter("rejected_task_total", "pool", "order").increment();
        log.warn("Task rejected: {}", r);
    }
);

调优没有银弹。最常被忽略的是：不结合 GC 日志看线程栈，不对比 ThreadPoolExecutor.getCompletedTaskCount() 和 getTaskCount() 的差值，就无法判断线程池是否真正在“扛住”压力，还是靠队列硬撑。