cachedthreadpool在高并发下易致oom，因无上限线程创建+栈内存耗尽触发“unable to create new native thread”；其用synchronousqueue无缓冲，空闲回收滞后，应改用有界队列、限最大线程数的threadpoolexecutor。
Java 中 CachedThreadPool 在高并发下容易导致内存溢出，核心原因不是“内存泄漏”，而是线程创建失控 + 线程栈资源耗尽，最终触发 java.lang.OutOfMemoryError: unable to create new native thread。
线程数无上限，迅速突破系统限制
Executors.newCachedThreadPool() 创建的线程池没有核心线程，最大线程数设为 Integer.MAX_VALUE（约 21 亿）。当任务持续涌入且执行缓慢（如含 I/O 等待、sleep 或阻塞），线程池会不断新建线程来处理新任务。
- 每个 Java 线程默认占用约 1MB 栈空间（可通过
-Xss调整，但通常不调小） - 假设服务器允许创建 1000 个线程，1000 × 1MB = 1GB 栈内存；若实际创建 2000+ 线程，极易超出 JVM 堆外内存或操作系统线程数上限
- Linux 系统对单进程线程数有限制（如
/proc/sys/kernel/threads-max），超限后直接抛出 “unable to create new native thread”
空闲线程回收延迟，加剧资源堆积
虽然 CachedThreadPool 声称“60 秒空闲后回收线程”，但该机制依赖线程主动退出并被清理。在以下场景中，回收往往滞后甚至失效：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
- 大量任务排队等待执行，新线程持续创建，旧线程尚未进入空闲状态
- 线程执行中发生长时间阻塞（如数据库连接未超时、网络请求挂起），无法按时释放
- 线程池未被显式关闭，JVM 运行期间线程对象长期驻留，占用 native memory
缺乏队列缓冲，压力全部转嫁到线程创建
与 FixedThreadPool 或自定义 ThreadPoolExecutor 不同，CachedThreadPool 使用的是 SynchronousQueue —— 它不存储任务，仅做“移交”。这意味着：
- 没有缓冲能力：任务无法排队，必须立刻有空闲线程承接，否则就新建线程
- 突发流量下，线程创建速率与任务提交速率几乎 1:1，放大系统压力
- 无法配合拒绝策略（如
CallerRunsPolicy）进行背压控制，失去流量削峰能力
替代方案：用可控线程池代替 CachedThreadPool
高并发场景下应避免直接使用 newCachedThreadPool()，推荐改用显式配置的 ThreadPoolExecutor：
- 设定合理的 核心线程数（如 CPU 核心数 + 1～2，I/O 密集型可适当提高）
- 限制 最大线程数（如 50～200，根据系统资源和业务 SLA 确定）
- 选用 有界队列（如
new LinkedBlockingQueue(200)），防止任务无限堆积 - 配置明确的 拒绝策略（如
AbortPolicy或CallerRunsPolicy），让上游感知压力 - 设置合适的 keepAliveTime（如 60 秒），平衡复用与资源释放
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
