线程过多导致OOM，Java如何排查？

本文深入剖析了Java中“unable to create new native thread”这一典型错误的本质——它并非堆内存不足引发的OOM，而是操作系统因线程资源耗尽（如超出threads-max或RLIMIT_NPROC限制）而拒绝分配新线程所致；文章清晰区分了该问题与Java堆内存溢出的根本差异，系统梳理了线程数暴增的常见诱因（如滥用newCachedThreadPool、裸写new Thread、JNI泄漏等），并提供了从系统级命令（ps、pstack、/proc/limits）到JVM工具（jstack、jstat）的实操排查路径，强调通过线程状态模式识别真实瓶颈（如大量阻塞在socketRead0或匿名Thread命名暴露代码缺陷），最后指出根治关键在于保障线程及时释放而非盲目调参，为开发者提供了一套兼具原理深度与落地价值的线程问题诊断与优化指南。

为什么 unable to create new native thread 不是堆内存问题

这个错误和 OutOfMemoryError: Java heap space 完全不是一回事——它不反映堆不够，而是操作系统拒绝给 JVM 新的线程资源。JVM 每建一个线程，就要向 OS 申请一块栈空间（默认 Linux 下约 1MB），还要分配线程描述符、内核调度结构等。一旦超出系统限制（比如 /proc/sys/kernel/threads-max 或每个进程的 RLIMIT_NPROC），就会直接抛出这个异常。

常见诱因包括：
- 线程池未复用，每次请求都 new Thread().start()
- 使用了无界队列 + 无限扩容的线程池（如 Executors.newCachedThreadPool() 在高并发下疯狂创建）
- Native 层 JNI 调用泄漏了线程（较少见，但排查时不能忽略）

怎么快速确认是不是线程数真爆了

别急着改代码，先看事实：

• 查当前进程线程数：ps -T -p | wc -l（注意第一行是标题，实际线程数减 1）
• 对比系统上限：cat /proc//limits | grep "max user processes"
• 看线程栈占用：pstack | wc -l（粗略估算，大量线程时可能卡顿）
• JVM 内部统计更准：用 jstack 输出里数 "java.lang.Thread.State" 出现次数，或直接 jstat -gc 看 NGCMN/NGCMX 和堆无关，但 jstat -t 配合时间戳可观察线程增长趋势

Executors.newCachedThreadPool() 为什么在生产环境很危险

它底层用的是 SynchronousQueue + 无上限的 ThreadPoolExecutor，任务来一个就新建线程，空闲 60 秒才回收。流量突增时，几十万请求进来，线程数可能瞬间冲到几千甚至上万。

替代方案必须带明确边界：

• 用 newFixedThreadPool(n)：线程数固定，但队列默认无界，仍可能 OOM 堆 —— 所以要配自定义 BlockingQueue，比如 new ArrayBlockingQueue(1000)
• 更推荐手动构造 ThreadPoolExecutor：显式指定 corePoolSize、maximumPoolSize、workQueue 和 RejectedExecutionHandler
• 避免在循环里调用 execute() 前不加限流，尤其配合远程调用或文件读写时，响应慢会进一步堆积任务

线程 dump 里哪些线索最值得盯

jstack 输出里，光看线程总数不够，得抓模式：

• 大量线程处于 java.lang.Thread.State: TIMED_WAITING (parking) 并堆在 Unsafe.park —— 很可能是线程池空闲线程，正常；但如果数量远超 maximumPoolSize，说明没生效
• 一堆线程卡在 java.net.SocketInputStream.socketRead0 或类似 IO 阻塞点，且名字像 pool-1-thread-1234：说明业务逻辑里有同步阻塞调用（如 HTTP 同步客户端、数据库长查询），线程被占住无法释放
• 出现大量 Finalizer、Reference Handler 或名字含 DestroyJavaVM 的线程：基本可排除，它们是 JVM 自身线程
• 注意线程名：如果全是 Thread-12345 这种匿名名，大概率是代码里裸写了 new Thread(...).start()

线程数问题的根因往往不在“创建”动作本身，而在“不释放”——比如忘了 close() 数据库连接导致连接池耗尽，进而让业务线程卡死等待连接，新请求只能不断开新线程顶上。所以看到线程暴涨，先查下游依赖是否健康，比立刻调大 -Xss 或系统 limits 更有效。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~