不要用 Executors 的原因

newFixedThreadPool 使用无界 LinkedBlockingQueue，任务堆积时内存风险高；newCachedThreadPool 最大线程 Integer.MAX_VALUE，可能打爆 CPU。

推荐创建方式

ThreadPoolExecutor 显式参数 + 有界队列 + 自定义 ThreadFactory（命名 prefix 方便 jstack）+ RejectedExecutionHandler 记录指标。

隔离与关闭

不同业务用独立线程池，避免慢任务拖垮快任务。shutdown → awaitTermination → shutdownNow 是优雅关闭模板，配合 Spring 的 @PreDestroy 或 JVM hook。

监控项

活跃线程数、队列深度、拒绝次数、任务耗时 P99。队列持续满且 active≈max，说明下游瓶颈而非简单「加线程」。

课堂外的思考

学习「Java 线程池最佳实践」时，我把自己放在线上值班的情境里：如果告警与这一主题相关，我能否在较短时间内建立假设并用数据验证？这种提问方式逼迫我从「看过」变成「讲得清楚、做得到」，也避免笔记沦为标题摘抄。

与同事的讨论方式

我会用白板画出状态机、内存布局或调用链，请同事挑错。若被追问「更高并发或更老 JDK 版本会怎样」，答不上来就回到文首原文链接查 primary source，而不是凭记忆硬编。讨论后把新认识补进笔记末尾。

可复现实验

为每个主题保留最小复现：一段可运行的 Java 片段、一条 jcmd/jstack 命令，或一组压测对比。记录环境（JDK 小版本、CPU 核数、容器限制），结论才可靠。实验细节不必全部公开，但索引要能找到。

补充复习

把本篇三个关键词写入间隔重复卡片，并各关联一个真实项目场景；暂时用不到的概念标记「待实践」，避免笔记只增不用。