应先用jstack和ps -T确认线程数暴增及OS级线程耗尽，再排查未关闭线程、第三方库泄漏及线程池配置不当（如newCachedThreadPool无界问题），而非盲目调大ulimit或-Xss。
Java线程数暴涨导致 java.lang.OutOfMemoryError: unable to create new native thread 怎么快速定位
这个错误不是堆内存不够，而是操作系统层面的线程资源耗尽了。JVM 每个线程都需要分配栈空间（默认 1MB），还要占用内核线程、文件描述符等资源。先别急着调大 -Xss，得先确认是不是线程真的在疯长。
实操建议：
- 用
jstack <pid></pid>看线程总数和堆栈分布，重点关注java.lang.Thread.State: RUNNABLE或大量WAITING却不退出的线程组 - 用
ps -T -p <pid> | wc -l</pid>（Linux）或top -H -p <pid></pid>验证 OS 层面线程数是否逼近系统限制（/proc/sys/kernel/threads-max） - 检查是否有未关闭的
new Thread(...).start()、匿名线程、定时任务未取消、或第三方库（如某些老版本 Druid、Netty）内部泄漏线程
为什么不能靠增大 ulimit -u 或 -Xss 来治本
调高系统线程上限或缩小单线程栈大小，只是把爆炸点往后推——它掩盖了线程生命周期失控的问题。更危险的是，小栈可能导致 StackOverflowError，尤其在深度递归或框架反射调用多的场景。
关键差异：
立即学习“Java免费学习笔记（深入）”；
-
ulimit -u是 per-process 的最大用户态线程数，受/proc/sys/kernel/pid_max和可用内存共同制约；盲目调高可能挤占其他进程资源 -
-Xss缩小后，ForkJoinPool或CompletableFuture在并行流中容易因栈不足失败，且对排查栈溢出无帮助 - 真正该盯的是：线程创建路径是否收敛？是否复用？是否随请求量线性增长？
线程池配置不当是 OOM 最常见原因，重点查这三处
很多服务把 Executors.newCachedThreadPool() 当万能解药，但它底层用的是无界 SynchronousQueue + Integer.MAX_VALUE 核心线程数，请求高峰时会无限新建线程直到炸掉。
安全做法：
- 拒绝使用
Executors.newCachedThreadPool()和Executors.newFixedThreadPool(n)—— 前者无界，后者队列用的是LinkedBlockingQueue（无界），两者都绕过了背压控制 - 显式构造
ThreadPoolExecutor，核心参数必须设限：corePoolSize（建议 CPU 核数+1～2）、maximumPoolSize（≤200，视 IO 密集度调整）、workQueue用有界队列（如new ArrayBlockingQueue(1000)） - 务必设置
RejectedExecutionHandler，至少用ThreadPoolExecutor.CallerRunsPolicy把压力回传给调用方，而不是静默丢任务或新建线程
Spring Boot 应用里线程池没生效？检查这些隐式覆盖点
Spring Boot 自动配置的线程池（如 @Async 默认用的 SimpleAsyncTaskExecutor）默认不复用线程，每个任务起一个新线程——这是线上 OOM 的高频雷区。
必须显式覆盖：
- 定义
@Bean类型为TaskExecutor，名字叫taskExecutor才能被@Async自动拾取；否则 fallback 到非复用型执行器 - 避免在
@Configuration类里直接 newThreadPoolTaskExecutor后只调setCorePoolSize()，忘了调initialize()—— 这会导致实际运行时仍用默认执行器 - Web 场景下，
ServletWebServerFactory（如 Tomcat）的maxThreads也要同步审视，它和业务线程池是两套资源，但共用 JVM 进程限额
线程不是越“多”越好，而是越“可控”越稳。最麻烦的不是配置错，是根本没意识到某个 SDK 内部偷偷开了守护线程池，还从不 shutdown。
