17370845950

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()，本质是“手递手”传递任务。

选错队列类型会直接改变线程池的扩容逻辑：

• 用 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 毫秒后就消失——几乎等于没用。