应手动构建 ThreadPoolExecutor 而非使用 Executors.newFixedThreadPool：因其采用无界队列、不可调参、线程永驻，易致 OOM；需设 有界队列、明确拒绝策略、可命名线程工厂，并启用 allowCoreThreadTimeOut、监控队列与活跃线程数。
Java 中 Executors.newFixedThreadPool(int nThreads) 看似简单，实则隐藏关键风险：它用的是无界队列 + 不可调参的封装实例，生产环境直接使用极易引发 OOM 或任务堆积。真正可控的做法是绕过工厂方法，手动构建 ThreadPoolExecutor。
FixedThreadPool 的真实构造逻辑
该方法底层等价于：
- 核心线程数 = 最大线程数 = nThreads
- 空闲存活时间为 0L，但
allowCoreThreadTimeOut默认为 false → 所有线程一旦创建就永不销毁 - 任务队列是 LinkedBlockingQueue（无界）→ 提交速度 > 消费速度时，内存持续增长
- 返回的是包装后的
ExecutorService，不暴露ThreadPoolExecutor实例 → 无法动态调整参数或获取队列状态
为什么不能只靠“设个数”就上线
固定线程数只是表象，真正决定稳定性的三个要素缺一不可：
-
有界队列：如
ArrayBlockingQueue(1024)，防止任务无限堆积 -
明确拒绝策略：比如
CallerRunsPolicy（调用线程自己执行）或自定义策略，让系统具备背压能力 -
可识别的线程工厂：用
ThreadFactoryBuilder.setNameFormat("order-processor-%d")替代默认的pool-1-thread-1，方便日志追踪与问题定位
推荐的替代写法（生产可用）
以下是一个兼顾资源控制、可观测性与失败应对的典型配置：
立即学习“Java免费学习笔记（深入）”；
- 核心/最大线程数设为 CPU 核心数 + 1（IO 密集型可略高，如 ×2）
- 队列容量按业务平均并发量预估，建议 ≤ 2000，避免单次毛刺打满
- 启用
allowCoreThreadTimeOut(true)，使空闲核心线程也能回收（需自行 new ThreadPoolExecutor） - 搭配监控：定期采集
executor.getQueue().size()和executor.getActiveCount()，设置阈值告警
shutdown 之后线程还不退出？这是设计使然
shutdown() 只是停止接收新任务，并等待已有任务自然结束 —— 它不会中断正在运行的线程。若任务阻塞在 IO 或死循环中，线程池将一直 hang 住：
- 任务代码中必须响应中断：
if (Thread.interrupted()) return;或捕获InterruptedException - 对网络/文件操作加超时，如
socket.setSoTimeout(3000) - 调用
awaitTermination(30, TimeUnit.SECONDS)后，再考虑shutdownNow()发送中断信号
