newfixedthreadpool() 不自动回收空闲线程且使用无界队列，易致oom和内存泄漏；应手动构建threadpoolexecutor，设为有界队列、开启allowcorethreadtimeout、自定义threadfactory并配置拒绝策略。
newFixedThreadPool() 创建的线程池会复用线程，但不自动回收空闲线程
它返回的是 ThreadPoolExecutor 的一个封装实例，底层实际是调用 new ThreadPoolExecutor(corePoolSize, corePoolSize, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<runnable>())</runnable>。这意味着：核心线程数 = 最大线程数，且空闲线程存活时间为 0 毫秒 —— 理论上应立即终止，但因为 allowCoreThreadTimeOut(false) 是默认关闭的，所以所有线程一旦创建就会一直存活，直到线程池被显式 shutdown()。
- 如果你需要空闲线程自动销毁（比如节省资源），不能依赖
newFixedThreadPool()，得直接构造ThreadPoolExecutor并调用allowCoreThreadTimeOut(true) - 队列用的是无界
LinkedBlockingQueue，任务持续提交又消费不及时时，会导致 OOM —— 这是生产环境最常踩的坑 - 线程名默认为
pool-N-thread-M，不利于排查问题；建议通过ThreadFactory自定义命名
如何避免 newFixedThreadPool() 导致的内存泄漏和 OOM
根本问题是无界队列 + 不可控的任务堆积。比如下游接口响应变慢，上游仍持续 submit()，任务就在队列里越积越多。
- 改用有界队列：绕过
Executors.newFixedThreadPool()，手写new ThreadPoolExecutor(n, n, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(1000)) - 设置拒绝策略：例如
new ThreadPoolExecutor.AbortPolicy()（抛RejectedExecutionException）或CallerRunsPolicy()（让提交线程自己执行任务） - 监控队列长度：可通过
executor.getQueue().size()定期采样，配合告警
为什么 shutdown() 后线程没立刻结束？
shutdown() 只是停止接收新任务，并等待已提交任务完成；它不会中断正在运行的线程。如果某个任务阻塞在 I/O 或无限循环中，线程池就无法真正关闭。
- 务必在任务逻辑中响应中断：检查
Thread.interrupted()或捕获InterruptedException - 对阻塞操作加超时：如
socket.read()改为socket.setSoTimeout(5000); socket.read() - 调用
awaitTermination()等待合理时间后，再考虑shutdownNow()强制中断 —— 但注意这仅是“建议中断”，不保证立即生效
替代方案：用 ThreadFactory 控制线程生命周期和可观测性
默认线程工厂创建的线程缺乏上下文信息，出问题时难以关联日志。手动传入自定义 ThreadFactory 是低成本高回报的做法。
ThreadFactory namedFactory = r -> {
Thread t = new Thread(r);
t.setName("biz-task-pool-" + t.getId());
t.setDaemon(false); // 非守护线程，避免 JVM 退出时被强杀
return t;
};
ExecutorService executor = new ThreadPoolExecutor(
4, 4, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue(100),
namedFactory,
new ThreadPoolExecutor.CallerRunsPolicy()
);
这里的关键点是：线程名带业务前缀、非守护线程、有界队列、拒绝策略明确 —— 这些都不是 newFixedThreadPool() 默认提供的，但恰恰是线上稳定运行所必需的。
别把 newFixedThreadPool() 当成开箱即用的“安全选项”；它的简洁掩盖了太多隐性约束。真正要用好，就得拆开看它背后那个 ThreadPoolExecutor 实例。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
