executors.newcachedthreadpool()因corepoolsize=0、maximumpoolsize=integer.max_value、workqueue=synchronousqueue，导致无缓冲、无限扩容、零背压，高峰易引发线程爆炸与oom。
因为 Executors.newCachedThreadPool() 的设计机制，本质上就是“来多少任务就开多少线程”，完全不设上限，也不缓冲任务——它在瞬时高峰下不是“扛不住”，而是主动“放任自流”。
核心原因：无界 + 零核心 + 无限扩容
看它的默认构造源码：
public static ExecutorService newCachedThreadPool() {<br> return new ThreadPoolExecutor(0, Integer.MAX_VALUE,<br> 60L, TimeUnit.SECONDS,<br> new SynchronousQueue<runnable>());<br>}</runnable>
关键三点直接埋雷：
- corePoolSize = 0：没有常驻线程，所有线程都是“临时工”，但又不真临时——只要60秒内有新任务，就复用；可一旦并发突增，立刻新建
- maximumPoolSize = Integer.MAX_VALUE（21.4亿）：这不是“够用就好”，而是“理论上永不拒绝”，系统撑爆前都不会主动限流
- workQueue = SynchronousQueue：这个队列不存任务，只做“手递手”交接。任务一提交，若无空闲线程，就立即创建新线程——零缓冲、零等待、零背压
高峰场景下线程爆炸的真实路径
假设一次用户请求触发5个异步日志上报任务，QPS 突然冲到 2000：
- 每秒涌入 2000 × 5 = 10,000 个任务
- SynchronousQueue 拒绝缓存 → 每个未被消费的任务都触发新建线程
- 线程池在几毫秒内就拉起上千线程（JVM 每线程默认占 1MB 栈空间 → 1000 线程 ≈ 1GB 内存）
- 操作系统线程资源（
/proc/sys/kernel/threads-max）快速触顶，fork: cannot allocate memory报错开始出现
为什么“过一会儿线程数又降了”，却更危险？
keepAliveTime=60秒看似有回收机制，但问题在于：
- 线程销毁是“被动等待”，不是“主动控量”：只有空闲满60秒才回收，高峰期间永远有任务进来，线程持续堆积
- 线程数剧烈抖动（比如从 50→3200→800→2500）会引发高频上下文切换，CPU 花在调度上而非干活，响应延迟飙升
- 监控看到“回落”容易误判为“已恢复”，实则系统已在崩溃边缘反复横跳
替代方案：用可控的线程池守住底线
别封装工具类返回 newCachedThreadPool，直接手动构建：
- 用
ArrayBlockingQueue(1000)替代 SynchronousQueue：任务排队，不盲目扩线程 - 设
corePoolSize = CPU核数+1～2，maximumPoolSize ≤ 200（IO密集型可略高，但必须有硬上限） - 拒绝策略选
CallerRunsPolicy：让调用方自己执行任务，自然降低流入速度，形成真实背压 - 务必命名线程（
ThreadFactoryBuilder.setNameFormat("log-pool-%d")），方便 jstack 定位
