线程池下一圈：参数从流量算出来，满了怎么办要提前想好

• 线程数拍脑袋：CPU 密集的活开 200 个线程，互相抢核、切换（线程页实验 1：512 个线程慢 36%）；等下游的活只开 8 个，CPU 闲着、请求排长队。
• 队列不设上限：Executors.newFixedThreadPool 的队列是 21 亿，下游一慢就一直堆，最后 OOM（上一页坑 4）。
• 拒绝策略用默认的：AbortPolicy 抛异常，调用方没 catch，下单接口直接 500。
• 配错了只能改代码发版，而流量高峰时最不该发版。
• 缺的那一块：参数从流量推出来，满了的代价提前选好，还能在线改、看得见。

不懂这一点时的典型误用：给通知池配 CallerRunsPolicy，觉得“不丢任务最安全”。实测 池子满了以后，提交通知的线程自己去发通知，提交 100 条从 9 ms 变成 363 ms。在全景里提交方是 Tomcat 的 exec 线程：下单接口每次都多卡一个通知的时间（⑤）。

选择规则：参数先算、再压测；满了先想“能不能丢”，能丢的选 Discard，不能丢又不能慢的放消息队列，宁可慢也不能丢的才用 CallerRuns；参数要能在线改、要有监控。本页学怎么算、四种策略、在线改、监控和关闭。

④-1怎么配：两个公式，一个计算器

计算器的公式就是上面三条；“核心”取平时需要的线程数，“最大”取高峰需要的数，都不超过 CPU 上限。算出来只是起点，最后看压测和监控（④-4）。

④-2满了：四种拒绝策略，代价转给了谁

• 1自己实现 RejectedExecutionHandler 更常见：记一条日志和一个指标，再把任务写进消息队列或数据库稍后补发。拒绝不该是悄悄发生的。
• 2CallerRuns 不是“不丢”：池子已经 shutdown 时它也直接丢（源码第一行就是 if (!e.isShutdown())）。

④-3运行中改大小：顺序和效果

• 1调大：先 setMaximumPoolSize，再 setCorePoolSize。JDK 9 起核心数不能大于最大数，顺序反了直接抛 IllegalArgumentException（实测）。调大核心时，源码会立刻按“队列里有几个任务”预先建线程，所以积压的任务马上开始被消化，不用等下一次 execute。
• 2调小：先核心后最大。多出来的线程不会被杀，源码只是 interruptIdleWorkers() 叫醒空闲的线程，让它们在下一次取任务时发现“超了”而自己退出；正在干活的线程干完才走。
• 3队列长度改不了：LinkedBlockingQueue、ArrayBlockingQueue 的容量是 final 的。想在线调队列，要换成一个容量能改的自定义队列（动态线程池框架都这么做）。

④-4监控：看这五个数

getActiveCount、getCompletedTaskCount 要拿池子的 mainLock、遍历所有 Worker，是近似值，别每毫秒调一次。Spring Boot 的 Actuator 会给它自己建的任务执行器注册 executor.* 指标（Micrometer 的 ExecutorServiceMetrics），自己 new 的池子要手动绑定。

④-5优雅关闭：三步

• 1shutdown()：不再接新任务（再提交就走拒绝策略），队列里的和正在跑的继续做完。
• 2awaitTermination(超时)：等它们做完，最多等这么久，返回是否全部结束。
• 3shutdownNow()：给所有工作线程发中断，返回队列里还没开始的任务。正在跑的任务只有响应中断才会停（线程页坑 2）；退回来的任务要自己记下来补发。

④-6为什么这样设计：把“满了”交给调用方决定

决定胜负的约束：资源一定是有限的。池子早晚会满，区别只在于“满了”这件事是在设计时被想好，还是在 OOM 时被发现。JDK 给了有界的工具和四种默认答案，但哪个对，只有业务知道。

ThreadPoolExecutor notifyPool = new ThreadPoolExecutor(
    10, 20, 60, TimeUnit.SECONDS,                      // 核心、最大、空闲多久回收
    new ArrayBlockingQueue<>(400),                     // 有界
    namedFactory("notify-"),                           // 起名字（线程页规范 1）
    (r, ex) -> { rejected.increment(); retryLater(r); });   // 自己的拒绝策略：记数 + 补发

notifyPool.setMaximumPoolSize(32);                     // 在线调大：先最大
notifyPool.setCorePoolSize(16);                        //          再核心

notifyPool.shutdown();
if (!notifyPool.awaitTermination(30, TimeUnit.SECONDS)) {
  List<Runnable> left = notifyPool.shutdownNow();     // 没做完的记下来补发
}

Spring 的 ThreadPoolTaskExecutor 怎么配、Boot 关机时怎么等任务、虚拟线程要不要池化，放到第⑥步。

实验 1：核心 2、最大 4、队列 10，一口气提交 100 条通知，每条 20 ms

• 1池子一次最多容纳 2（核心）+ 10（队列）+ 2（扩到最大）= 14 条，所以三种丢弃类的策略都只发出 14 条。区别只在丢谁、告不告诉你：Abort 抛异常，Discard 悄悄丢新的，DiscardOldest 悄悄丢老的（它留下的是最后进来的那 10 条）。
• 2CallerRuns 一条不丢，代价是提交方 main 自己发了不少通知，提交 100 条从 9 ms 变成 363 ms，慢了 40 倍。放到全景里，就是第 10 站把通知的耗时加回到了下单请求上。

实验 2：核心 2、最大 2，压进 400 条，第 500 ms 在线调到 16

$ java -cp … LiveResize
先 setCorePoolSize(16)（大于当前最大 2）：抛 IllegalArgumentException
  时间ms  线程数  活跃  排队  已完成
      0       2     2   398       0
    120       2     2   387      11
    321       2     2   366      32
    523       2     2   346      52
   ↑ 第 523 ms：setMaximumPoolSize(16) 再 setCorePoolSize(16)，线程数马上变成 16
    625      16    16   258     126
    728      16    16   172     212
    829      16    16    92     292
    930      16    16    12     372
400 条全部发完：1030 ms（全程 2 个线程要约 4000 ms）

== 优雅关闭 ==
shutdown 之后再提交：RejectedExecutionException
等 500 ms：没做完，已做完 16 个，队列里还有 8 个
shutdownNow：退回没开始的 8 个，被中断的 16 个，做完的共 16 个

• 1调大的那一刻，线程数直接从 2 变 16，不用等新任务来：setCorePoolSize 里按队列里的任务数预先建了线程。每 100 ms 完成数从约 10 涨到约 85，约 8 倍。
• 2关闭：40 个 300 ms 的任务，16 个线程第一批做完 16 个，第二批 16 个刚开始就被 shutdownNow 中断，队列里剩下的 8 个原样退回。实际生产里，这 24 个都要记下来补发。

• 可变容量的阻塞队列：照着 LinkedBlockingQueue 改一个 setCapacity，接配置中心做完整的动态线程池
• ScheduledThreadPoolExecutor 和 DelayedWorkQueue：固定频率任务的“漂移”（上一圈列过）
• ForkJoinPool：工作窃取和 CompletableFuture 的默认池（下一个知识点会用到）
• Micrometer 给线程池注册指标，Grafana 画排队时间（J13）
• 按“排队时间”而不是“排队个数”拒绝：给任务打上入队时间，超时的直接丢（J12）

自测