生产环境禁用executors.newfixedthreadpool()，因其使用无界linkedblockingqueue易致oom；应手动构建threadpoolexecutor，配arrayblockingqueue、callerrunspolicy拒绝策略及命名threadfactory，并加强运行时监控。
直接用 Executors.newFixedThreadPool() 在生产环境极易引发堆内存溢出（OOM），核心问题不是线程数，而是它背后那个“看似有界、实则无界”的 LinkedBlockingQueue(Integer.MAX_VALUE)。任务持续堆积时，每个 Runnable 携带的上下文对象（如 HTTP 请求体、数据库参数、DTO 图）会不断占用堆内存，积压几千个就可能吃掉 1GB+，最终触发 java.lang.OutOfMemoryError: Java heap space。
换成手动构造 ThreadPoolExecutor
必须绕过 Executors 工厂方法，显式控制三大关键参数：
- 用
ArrayBlockingQueue替代LinkedBlockingQueue，并指定合理容量（例如new ArrayBlockingQueue(256)） - 拒绝策略设为
CallerRunsPolicy：队列满时由提交线程自己执行任务，天然实现反压，防止任务无节制涌入 - 传入命名的
ThreadFactory，比如用ThreadFactoryBuilder设置格式为"biz-notify-%d"，便于排查和监控
线程数与队列容量要匹配
固定规模不等于安全，关键在“上限可见”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 核心线程数 = 最大线程数（如都设为 8），保持稳定调度能力
- 但必须配合有界队列——如果队列设为 256，那系统最多缓冲 256 个待处理任务，超出即触发拒绝策略，不会静默堆积
- 避免把队列容量设得过大（如 10000），这等于把 OOM 延后，而非规避
加上基础运行时监控
工厂方法封装太深，连基本指标都拿不到。手动构造后可轻松接入监控：
- 调用
getQueue().size()实时查看积压量，超过阈值（如 80% 队列容量）告警 - 用
getActiveCount()观察当前活跃线程数，判断是否已打满 - 结合 Micrometer 或 Prometheus 暴露这些指标，纳入统一告警体系
其他 Executors 方法同样禁用
别只盯住 newFixedThreadPool，整个 Executors 工具类在生产中都不推荐：
-
newCachedThreadPool()：最大线程数为Integer.MAX_VALUE，高并发下线程疯涨，容易栈溢出或 CPU 打满 -
newSingleThreadExecutor()：同样基于无界队列，且被FinalizableDelegatedExecutorService封装，无法转型、无法调参、异常后线程静默死亡
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
