corepoolsize过小会导致高并发时任务大量排队、触发拒绝策略，并在流量突增时因频繁创建销毁线程而增加gc和上下文切换开销；建议不低于4，io密集型可设8–16。
corePoolSize 设置过小会导致什么问题
线程池刚创建时，即使没有任务提交，也不会立即创建核心线程；只有当任务到来且当前线程数 corePoolSize 时，才会新建线程执行。如果 corePoolSize 设为 1，但并发请求有 50 个，前 1 个任务被处理，其余 49 个会先进入 workQueue（假设队列未满），看似“没压力”——但一旦队列也满了，后续任务就会触发拒绝策略。
更隐蔽的问题是：在流量突增场景下，corePoolSize 过小 + keepAliveTime 较短，会导致线程反复创建销毁，增加 GC 和上下文切换开销。
- 典型错误：把
corePoolSize固定设为 1 或 2，误以为“省资源”，实际放大了排队延迟 - 建议值：参考系统平均并发请求数 × 单任务平均 CPU 耗时占比，通常不低于 4；IO 密集型可适当提高（如 8–16）
- 注意：若使用
allowCoreThreadTimeOut(true)，哪怕corePoolSize > 0，空闲核心线程也会被回收，此时行为等同于maximumPoolSize的动态伸缩
workQueue 用 LinkedBlockingQueue 还是 SynchronousQueue
LinkedBlockingQueue 是有界/无界链表队列，插入不阻塞（除非显式设了容量且已满）；SynchronousQueue 不存储元素，每个 put() 必须等待对应 take()，本质是“手递手”传递任务。
选错队列类型会直接改变线程池的扩容逻辑：
立即学习“Java免费学习笔记（深入）”；
- 用
LinkedBlockingQueue（尤其无界）：任务永远优先进队列，maximumPoolSize形同虚设，线程数卡死在corePoolSize，高并发时 OOM 风险极高 - 用
SynchronousQueue：任务无法入队，只要线程数 maximumPoolSize 就立刻新建线程，更接近“按需创建”，适合响应时间敏感、能接受瞬时线程增长的场景 - 折中方案：
ArrayBlockingQueue（有界）+ 合理容量（如 100–1000），既能缓冲突发流量，又能迫使线程池在队列满后扩容
拒绝策略不是兜底，而是信号
当线程数已达 maximumPoolSize 且 workQueue 已满时，新任务触发拒绝策略。默认的 AbortPolicy 直接抛 RejectedExecutionException，但很多人只 catch 异常，没意识到这是系统过载的明确信号。
-
CallerRunsPolicy：让调用线程自己执行任务，可减缓提交速度，但会阻塞业务线程，慎用于 Web 请求入口 - 自定义策略推荐记录指标：
public class MetricsRejectPolicy implements RejectedExecutionHandler { @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { Metrics.counter("threadpool.rejected", "name", executor.getThreadFactory().toString()).increment(); throw new RejectedExecutionException("Task " + r.toString() + " rejected from " + executor.toString()); } } - 关键点：拒绝发生 ≠ 线程池写错了，而可能是 QPS 超出设计容量、下游依赖变慢导致任务积压、或
workQueue容量与maximumPoolSize不匹配
keepAliveTime 对非核心线程的实际影响
keepAliveTime 只控制**超出 corePoolSize 的那些线程**的空闲存活时间。例如 corePoolSize=4、maximumPoolSize=10，当负载下降、线程数从 10 回落到 4 后，剩下的 6 个“临时工”线程会在空闲满 keepAliveTime 后被销毁。
- 设为 0L：非核心线程空闲即销毁，适合流量尖刺明显、要求快速缩容的场景（但频繁创建销毁代价高）
- 设为较长值（如 60L, TimeUnit.SECONDS）：保留更多线程应对短期波动，降低创建开销，但内存和句柄占用略高
- 陷阱：若
allowCoreThreadTimeOut(true)开启，则keepAliveTime同时作用于所有线程（包括 core），此时核心线程也不再“永久驻留”
真正容易被忽略的是：这个参数单位必须和传入的 TimeUnit 严格匹配；写成 new ThreadPoolExecutor(4, 10, 60, TimeUnit.MILLISECONDS, ...) 会导致非核心线程 60 毫秒后就消失——几乎等于没用。
