自定义ThreadFactory本身不直接导致OOM，但若缺乏线程总数约束，配合newCachedThreadPool或无界队列+缺失拒绝策略，易致线程数失控，触发“Unable to create new native thread”系统级OOM。
Java中自定义线程工厂（ThreadFactory）本身不会直接导致OOM，但它若缺乏对线程总数的约束，配合不当的线程池配置（如 newCachedThreadPool 或无界队列 + 拒绝策略缺失），就可能让线程数不受控地增长，最终触发 java.lang.OutOfMemoryError: Unable to create new native thread —— 这是一种典型的系统级内存耗尽，而非堆内存溢出。
为什么线程数失控会引发OOM
每个Java线程在操作系统层面都会创建一个对应的本地线程（native thread），占用独立的栈空间（默认 -Xss 为1MB左右）和内核资源（如线程ID、调度结构体）。当线程数量超过以下任一限制时，JVM就无法再创建新线程：
- 操作系统对单进程最大线程数的限制（
ulimit -u，常见默认值为1024或4096） - 系统可用虚拟内存不足（尤其在32位环境或物理内存紧张时）
- 内核参数
kernel.pid_max达到上限（影响可创建的总进程/线程ID数）
自定义ThreadFactory的典型风险点
很多开发者自定义 ThreadFactory 是为了统一命名、设置守护线程或添加上下文，但容易忽略“兜底控制”。例如：
- 仅重写
newThread(Runnable r)方法，未集成线程计数器或熔断逻辑 - 与
Executors.newCachedThreadPool()配合使用：该线程池允许空闲60秒后销毁线程，但高并发下仍可能瞬间创建数千线程，而自定义工厂未做任何拦截 - 静态计数器未加锁或未考虑多实例场景（如多个线程池共用同一工厂），导致计数失效
如何安全地实现带限流的ThreadFactory
核心思路是：在创建线程前检查当前活跃线程数是否已逼近系统或业务上限，并主动拒绝。推荐做法如下：
立即学习“Java免费学习笔记（深入）”；
- 使用
AtomicInteger安全记录已创建线程数，配合预设阈值（如Math.min(ulimit -u * 0.8, 500)） - 在线程创建失败时抛出
RuntimeException（如IllegalStateException("Thread limit exceeded")），促使上层线程池执行拒绝策略 - 避免在
newThread中做耗时操作（如远程调用、日志刷盘），防止阻塞线程池初始化 - 配合
ThreadPoolExecutor显式构造，禁用Executors工厂方法，确保能指定有界队列与拒绝策略
配套必须做的系统与JVM调优
仅靠线程工厂不够，需多层防护：
- 上线前执行
ulimit -a查看max user processes，必要时通过ulimit -u 8192提升（需root权限并写入/etc/security/limits.conf） - JVM启动参数加入
-Xss256k降低单线程栈大小（注意避免 StackOverflowError） - 线程池配置中明确设置最大线程数（如
maxPoolSize=200），不依赖“自动伸缩”幻想 - 监控
Thread.activeCount()或通过 JMX 的java.lang:type=Threading属性实时告警
