Executors.newFixedThreadPool() 因使用无界队列易致OOM，应改用显式配置的ThreadPoolExecutor，配ArrayBlockingQueue、合理拒绝策略及监控；shutdown()需配合awaitTermination()，keepAliveTime默认不作用于核心线程，allowCoreThreadTimeOut(true)可启用动态伸缩。
为什么 Executors.newFixedThreadPool() 在生产环境要慎用
它底层直接使用 LinkedBlockingQueue 且容量为 Integer.MAX_VALUE，任务持续提交时队列无限增长，极易引发 OOM。这不是线程不够用的问题，而是背压机制缺失导致的内存失控。
- 替代方案优先选
ThreadPoolExecutor手动构造，显式控制corePoolSize、maximumPoolSize、workQueue（如ArrayBlockingQueue）和RejectedExecutionHandler - 若必须用
Executors工厂方法，至少搭配自定义ThreadFactory（用于命名线程）和RejectedExecutionHandler（如CallerRunsPolicy） - 监控队列长度：通过
getQueue().size()定期采样，结合 Prometheus 暴露为指标，避免“等发现时已挂了”
如何正确处理线程池拒绝策略（RejectedExecutionHandler）
默认的 AbortPolicy 直接抛 RejectedExecutionException，但很多业务代码没做 try-catch，结果异常吞掉、任务静默丢失。这比慢一点更危险——你根本不知道任务没执行。
-
DiscardPolicy：静默丢弃，适合日志、埋点等非关键任务 -
DiscardOldestPolicy：丢弃队列头任务，再尝试提交当前任务；注意它不保证 FIFO，且可能反复挤掉同一任务 -
CallerRunsPolicy：由提交线程自己执行任务，可自然降速，但会阻塞调用方，需评估调用链是否允许 - 自定义策略推荐：记录被拒任务的
toString()+ 当前时间戳 + 线程池状态（getActiveCount()、getQueue().size()），方便事后回溯
线程池 shutdown() 和 shutdownNow() 的真实行为差异
shutdown() 只是停止接收新任务，已提交任务（包括队列中等待的）仍会执行完；shutdownNow() 尝试中断所有正在运行的线程，并返回队列中未执行的任务列表——但它不能保证线程真的停止，因为中断只是“建议”。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 调用
shutdown()后务必配合awaitTermination(long, TimeUnit)等待结束，超时后才考虑shutdownNow() - 在
Runnable或Callable中必须响应中断：检查Thread.currentThread().isInterrupted()，或捕获InterruptedException并恢复中断状态（Thread.currentThread().interrupt()） - 常见陷阱：JDBC 查询、OkHttp 请求、文件读写等阻塞操作不会自动响应中断，需主动设置超时（如
socketTimeout、connectTimeout）或使用可中断 API（如FileChannel.lock()的带 interrupt 版本）
ThreadPoolExecutor 的 keepAliveTime 对核心线程是否生效
默认情况下，keepAliveTime 只对非核心线程有效；但如果你调用了 allowCoreThreadTimeOut(true)，那么核心线程空闲超过该时间也会被回收。这是动态伸缩的关键开关，但多数人忽略它。
立即学习“Java免费学习笔记（深入）”；
- 适用场景：流量波峰波谷明显的服务（如定时报表生成），避免低峰期空耗线程资源
- 副作用：频繁创建/销毁线程有开销，且线程重建后 TLS（ThreadLocal）变量需重新初始化，可能引发 NPE 或脏数据
- 建议搭配
ThreadFactory使用：在newThread()中预设好关键ThreadLocal初始值，避免首次执行时判空逻辑出错
public class CustomThreadFactory implements ThreadFactory {
private final AtomicInteger threadNumber = new AtomicInteger(1);
private final String namePrefix;
public CustomThreadFactory(String namePrefix) {
this.namePrefix = namePrefix + "-thread-";
}
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r, namePrefix + threadNumber.getAndIncrement());
t.setDaemon(false);
// 预设关键 ThreadLocal
MyContext.initForThread(t);
return t;
}
}
线程池不是配置完就高枕无忧的组件，它的健康度取决于你是否真正理解每个参数在 GC、中断、阻塞 I/O、队列溢出等边界场景下的联动反应。尤其当服务接入分布式追踪或异步日志时，线程复用可能导致 MDC 透传失效、上下文污染——这些细节往往比“怎么建池”更决定线上稳定性。 
