java线程池oom主因是参数配置失当，需禁用executors工厂方法，手动构造含界队列、合理线程数、callerrunspolicy及命名线程工厂的可监控线程池。
Java 线程池发生 OOM，绝大多数不是因为代码写错，而是参数配置失当——尤其是 线程数失控 和 任务无限堆积 这两大典型问题。只要抓住核心参数间的制约关系，就能从根源上规避。
避免线程数爆炸：别让 maximumPoolSize 失控
每个 Java 平台线程默认占用约 1MB 栈空间（虚拟线程除外）。若将 maximumPoolSize 设为 Integer.MAX_VALUE 或过大值（如 1000+），高并发下瞬间创建数百线程，直接触发 java.lang.OutOfMemoryError: unable to create new native thread。
- CPU 密集型任务：设为
Runtime.getRuntime().availableProcessors()或 +1，避免上下文切换开销 - I/O 密集型任务：可设为
CPU核数 × (1 + 平均阻塞系数)，常见取值是 CPU核数 × 2～4，而非盲目放大 - 永远不要用
Executors.newCachedThreadPool()—— 它的maximumPoolSize是Integer.MAX_VALUE，本质就是“不限制”
防止任务队列吃光堆内存：必须用有界队列
无界队列（如 new LinkedBlockingQueue()）看似“不会拒绝任务”，实则是把压力转嫁给堆内存。当任务提交速度远高于处理速度时，队列持续膨胀，最终引发 java.lang.OutOfMemoryError: Java heap space。
- 首选
ArrayBlockingQueue，显式指定容量（例如 1000），容量需结合平均任务耗时、峰值 QPS 和可接受等待时长估算 - 避免使用
LinkedBlockingQueue的无参构造；若必须用，务必传入容量限制 - 对实时性要求高的场景（如秒杀），队列容量宁小勿大，靠拒绝策略兜底，比堆积更可控
拒绝策略不是摆设：要让它真正起作用
有界队列 + 合理的 maximumPoolSize 组合后，必然会出现任务无法入队或创建新线程的情况。此时拒绝策略就是最后一道防线。
-
AbortPolicy（默认）：直接抛异常，适合能主动降级或重试的调用方 -
CallerRunsPolicy：让提交任务的线程自己执行，天然限流，适合后台批处理类任务 - 自定义策略：记录日志 + 上报监控 + 触发告警，便于快速定位过载源头
- 切忌忽略拒绝策略的存在——它不是“出错了才看”，而是“设计时就该想好怎么错”
别忘了回收空闲资源：keepAliveTime 要设合理值
非核心线程（即超出 corePoolSize 的临时线程）如果长期不回收，会持续占用栈内存和系统资源。尤其在流量波峰过后，残留大量空闲线程会拖慢整体响应，间接加剧资源紧张。
- I/O 密集型任务可设较短值（如 10–60 秒），加快释放
- CPU 密集型任务可适当延长（如 2–5 分钟），减少频繁创建销毁开销
- 必要时启用
allowCoreThreadTimeOut(true)，让核心线程也参与超时回收（需配合较小的keepAliveTime）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
