“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+ 线程，就已逼近红线。
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
线程池必须设界，禁用无界队列
常见错误是用 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></pid>查看线程名、状态、堆栈深度；重点关注WAITING或BLOCKED线程是否堆积、是否有命名不规范的匿名线程 -
线程生命周期管控：禁止
new Thread(...).start()；所有异步必须走统一管理的ExecutorService，且在应用关闭时显式shutdownNow() -
监控埋点：暴露
ThreadPoolExecutor.getActiveCount()和getPoolSize()到Prometheus，设置 >80% 的告警阈值
