Executors.newCachedThreadPool()将最大线程数设为Integer.MAX_VALUE并非鼓励无限制创建线程，而是通过“快速扩容+快速回收”适配短期轻量任务，依赖60秒空闲回收与SynchronousQueue实现动态限流，并以失控风险倒逼开发者显式配置合理线程池参数。

Executors.newCachedThreadPool() 把最大线程数设为 Integer.MAX_VALUE，表面看是“高度可伸缩”，但深层逻辑不是为了鼓励无限制创建线程，而是用一种极简的默认策略，把资源边界控制权完全交给使用者——只是它没明说，反而埋了坑。

这个设计背后有三层现实考量：

• 面向短期、轻量、不可预测的任务模型
  它预设任务生命周期极短（毫秒级）、CPU占用低、提交频率波动大。比如处理大量 HTTP 短连接、RPC 回调、事件通知等。此时“快速扩容 + 快速回收”比“精打细算配线程”更符合响应性目标。设成 MAX_VALUE，本质是避免因上限过早触发拒绝策略，干扰这种弹性场景的默认流畅性。

• 依赖空闲回收机制替代硬性限制
  它的核心约束不在 maximumPoolSize，而在 keepAliveTime = 60L 和队列类型 SynchronousQueue。后者不缓存任务，必须有空闲线程立刻接住；没有空闲线程就新建——所以线程数量实际由「60秒内并发峰值」动态决定。MAX_VALUE 在这里只是“别拦着我建”，真正起限流作用的是时间维度的回收逻辑，而非数量维度的封顶。

• 暴露问题，倒逼显式建模
  Java 并发设计一贯倾向“fail fast + 显式契约”。把 maximumPoolSize 设得极大，等于在说：“你真需要这么多线程？那得你自己确认硬件、GC、上下文切换成本是否扛得住。” 这不是疏忽，而是用失控风险提醒开发者：当业务流量具备突发性、任务耗时不可控、或存在阻塞风险时，这个默认值就不再安全——该换 ThreadPoolExecutor 手动配置了。

换句话说，Integer.MAX_VALUE 不是兜底方案，而是一块警示牌：它不阻止你踩坑，但确保你踩的时候清楚听见响声。