最大线程数过大易致系统崩溃：线程栈耗尽内存引发fork失败或OOM Killer干预；上下文切换激增拖垮CPU；无界队列叠加大线程数引爆堆与本地内存溢出；并掩盖线程泄漏问题。
最大线程数（maximumPoolSize）设得过大，不是“多点线程更扛压”，而是直接把系统推到资源临界点——轻则响应变慢、GC 频繁，重则 OutOfMemoryError 或服务器级崩溃。
内存被线程栈吃光
每个 Java 线程默认分配约 1MB 栈空间（可通过 -Xss 调整，但多数生产环境保持默认）。若设 maximumPoolSize = 2000，仅线程栈就占用约 2GB 内存。当突发流量触发大量线程创建，JVM 堆外内存（native memory）迅速耗尽，可能表现为：
-
fork failed: Cannot allocate memory（Linux 创建新线程失败） - SSH 登录不上、进程无法启动（系统级 fork 失败）
- 应用未报 OOM，但整个 JVM 挂死或被 OS 杀掉（OOM Killer 干预）
CPU 被上下文切换拖垮
线程数远超 CPU 核心数时，操作系统需频繁调度、保存/恢复寄存器与栈状态。这种开销不处理业务，纯属“空转”：
-
vmstat中cs（context switch）值飙升数倍甚至十倍 - CPU 使用率显示 100%，但实际业务吞吐量不增反降
- 线程处于
RUNNABLE状态却长期得不到有效执行时间片
任务队列与线程数叠加引爆 OOM
最危险的组合是：无界队列 + 过大 maximumPoolSize。例如：
立即学习“Java免费学习笔记（深入）”；
LinkedBlockingQueue()（容量为 Integer.MAX_VALUE） + maximumPoolSize = Integer.MAX_VALUE此时线程池既不会拒绝任务，也不会限制堆积，导致：
- 任务对象持续入队，堆内存暴涨
- 电商秒杀场景曾因此在 5 分钟内堆使用率达 98%，最终
java.lang.OutOfMemoryError: Java heap space - 即使堆没满，native memory（如线程栈、DirectBuffer）也早已耗尽
线程泄漏风险被放大
最大线程数过大本身不直接造成泄漏，但它掩盖了真实问题：
- 本该因拒绝策略暴露的任务积压，被“无限扩容”掩盖
- 一个未正确 shutdown 的线程池，在容器重启不彻底时，每次部署都悄悄新增数百线程
- 线程数从几百缓慢涨到上万，运维监控只看到“线程数高”，却找不到源头
