CachedThreadPool的“句柄雪崩”指其无限制创建线程导致耗尽系统ulimit -u进程/线程数配额，引发fork失败、ssh卡死等系统级阻塞，而非堆内存溢出。
什么是 CachedThreadPool 的“句柄雪崩”
cachedthreadpool 是 executors.newcachedthreadpool() 创建的线程池，特点是：任务来一个就新建线程（无上限），空闲 60 秒后回收。它不复用线程，也不限制并发数——在 linux 上，每个线程默认对应一个轻量级进程（lwp），占用一个 task（即 “max user processes” 限制的对象）。
当大量短任务持续提交，而系统 ulimit -u 设置较低（如默认的 1024 或 4096）时，CachedThreadPool 会快速创建成百上千个线程，瞬间耗尽用户级进程/线程数配额。此时不仅你的程序卡死，连 ssh 登录、ps、ls 都可能失败——因为内核拒绝为新 task 分配资源。
用原生 Java 代码直观触发（无需 Spring/Docker）
以下代码仅依赖 JDK 8+，运行前建议先查当前限制：
$ ulimit -u # 查看当前最大用户进程数，常见值：1024、4096、8192
然后运行这段极简但“危险”的演示代码：
import java.util.concurrent.*;
public class CachedPoolHandleBomb {
public static void main(String[] args) throws InterruptedException {
// 使用无界队列 + 无限创建线程的 CachedThreadPool
ExecutorService pool = Executors.newCachedThreadPool();
System.out.println("Starting flood... (Ctrl+C to stop)");
int count = 0;
try {
while (true) {
pool.submit(() -> {
try {
// 每个线程只做微小工作，但足够存活 >1s，避免立即回收
Thread.sleep(1500);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
if (++count % 100 == 0) {
System.out.printf("Submitted %d tasks → estimated threads: ~%d%n",
count, count); // 实际线程数 ≈ 已提交未完成数
Thread.sleep(10); // 稍微控速，便于观察
}
}
} catch (Error | RuntimeException e) {
// 常见报错：java.lang.OutOfMemoryError: unable to create native thread
System.err.println("? BOOM! Thread creation failed: " + e.getMessage());
e.printStackTrace();
} finally {
pool.shutdown();
}
}
}运行后你会看到：
- 几秒内
ps -eL | grep java | wc -l快速突破 1000+ - 终端开始出现
fork: retry: Resource temporarily unavailable -
ulimit -u对应的值被占满，top显示大量 LWP（Threads 列飙升） - 其他用户或同一用户新开 shell 可能直接失败
为什么不是 OutOfMemoryError？而是系统级阻塞
JVM 报的异常常是 java.lang.OutOfMemoryError: unable to create native thread，但这不是堆内存不足，而是：
→ JVM 调用 pthread_create 失败
→ 内核返回 errno=11 (EAGAIN)
→ 原因正是 /proc/sys/kernel/threads-max 或更常见的是用户级限制 RLIMIT_NPROC（即 ulimit -u）已达上限
此时 jstack 可能已无法执行（因 jstack 自身也要 fork 新线程），cat /proc/$(pidof java)/status | grep -i threads 却能看到线程数爆炸式增长。
安全验证与防护建议
不要在线上环境直接运行上述代码。可在隔离环境（如 Docker 容器或 VM）中验证：
- 启动容器时加限制：
docker run --ulimit nproc=512:512 openjdk:17-jre ... - 用
strace -f -e trace=clone java ...监控线程创建系统调用，看到大量clone(... CLONE_THREAD ...) = -1 EAGAIN即命中瓶颈 - 替代方案：永远避免
newCachedThreadPool，改用newFixedThreadPool(n)或更优的newWorkStealingPool；生产代码务必使用ThreadPoolExecutor显式构造，设置corePoolSize、maxPoolSize和有界队列
本质问题不在线程池本身，而在“无约束并发”遇上操作系统硬限制——它不声不响，却能让整个用户会话瘫痪。
