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 控制空闲线程的存活时长，直接影响线程复用效率和资源占用。
默认单位是秒，但很多开发者没注意单位参数传错，导致线程几毫秒就销毁，或几小时不回收：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 设为
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 不一定最好
队列选型直接决定线程池行为模式：corePoolSize 是否被尊重、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() 的差值，就无法判断线程池是否真正在“扛住”压力，还是靠队列硬撑。
