“unable to create new native thread”本质是操作系统级资源耗尽，非JVM堆内存问题，而是线程创建时无法分配本地方法栈空间，受/proc/sys/kernel/threads-max、ulimit -u和/proc/sys/vm/max_map_count三重硬限制约。
物理线程数撑爆导致“unable to create new native thread”错误，本质是操作系统级资源耗尽，不是JVM堆内存问题，而是线程创建时无法分配本地方法栈（Native Stack）空间。解决核心在于：**控数量、降开销、查限制、配合理**。
看清系统级线程上限
每个线程需独占一块栈内存（Linux默认约1MB/线程），且受三重硬性限制：
- /proc/sys/kernel/threads-max：全系统最大线程总数，由内存和内核参数决定
- ulimit -u：当前用户能拥有的最大进程+线程数（注意：线程也计入此值）
- /proc/sys/vm/max_map_count：影响线程栈映射区域数量，过低会卡在mmap阶段
执行 cat /proc/sys/kernel/threads-max && ulimit -u && cat /proc/sys/vm/max_map_count 快速定位瓶颈点。若 ulimit -u 显示 4096，而应用已创建 4000+ 线程，就已逼近红线。
线程池必须设界，禁用无界队列
常见错误是用 LinkedBlockingQueue 配合 Integer.MAX_VALUE 最大线程数——任务积压时线程无限创建。正确做法：
- 用
SynchronousQueue或有界队列（如new ArrayBlockingQueue(1024)） - 核心线程数 ≤ CPU逻辑核数（
Runtime.getRuntime().availableProcessors()） - 最大线程数建议 ≤ 核数 × 2～4，绝不可盲目乘以100
- 拒绝策略必须显式指定（如
AbortPolicy或自定义日志告警策略）
调小单线程栈空间，但不治本
通过 JVM 参数 -Xss256k 可将每线程栈从默认1MB降至256KB，理论线程容量翻4倍。但这是权宜之计：
- 栈太小易触发
StackOverflowError，尤其含深度递归或大量局部对象的场景 - 未解决线程滥用根源，可能掩盖更严重的并发设计缺陷
- 仅适用于I/O密集型且栈使用极轻的业务线程（如纯Netty事件处理）
排查与加固双落地
上线前和故障后必须做两件事：
-
实时线程快照：用
jstack -l <pid>查看线程名、状态、堆栈深度；重点关注WAITING或BLOCKED线程是否堆积、是否有命名不规范的匿名线程 -
线程生命周期管控：禁止
new Thread(...).start()；所有异步必须走统一管理的ExecutorService，且在应用关闭时显式shutdownNow() -
监控埋点：暴露
ThreadPoolExecutor.getActiveCount()和getPoolSize()到Prometheus，设置 >80% 的告警阈值
