FixedThreadPool靠固定资源换确定性，CachedThreadPool靠动态伸缩换响应力：前者任务排队、资源恒定但可能堆溢出，后者几乎不排队、响应快但线程激增易OOM。
FixedThreadPool 和 CachedThreadPool 的核心性能差异，不在“快不快”，而在“怎么稳”和“怎么弹”。前者靠固定资源换确定性，后者靠动态伸缩换响应力。
响应速度与任务堆积表现不同
CachedThreadPool 任务一来就找空闲线程，没有就立刻建新线程——几乎不排队。只要系统还能创建线程，任务就能马上执行。但这也意味着：如果任务持续涌入且执行慢，线程数会猛涨，可能迅速耗尽内存或触发系统限制。
FixedThreadPool 所有任务必须排队等待，线程数卡死在设定值。任务提交快于处理时，队列会不断积压。表面看响应变慢，但资源占用始终可控；风险是队列无限增长（尤其用默认无界 LinkedBlockingQueue），最终撑爆堆内存。
资源开销波动特征相反
- CachedThreadPool：空闲时近乎零开销（线程全销毁），高峰时线程数飙升，CPU上下文切换剧烈，内存压力集中在运行时
- FixedThreadPool：从启动起就占用固定数量的线程栈内存，线程长期存活，上下文切换稳定，但内存占用恒定且不可降
失败模式与可观测性差异明显
CachedThreadPool 很少抛 RejectedExecutionException，除非系统级资源彻底枯竭（如无法 fork 新线程）。问题往往表现为延迟突增或 OOM，排查困难。
立即学习“Java免费学习笔记（深入）”；
FixedThreadPool 在队列满 + 所有线程忙时，会明确按默认策略（AbortPolicy）拒绝任务，直接抛异常。这反而利于监控告警——你一眼就知道“系统已饱和”，而不是在猜“是卡了还是崩了”。
适用负载节奏根本不同
不是“高并发选Cached、低并发选Fixed”，而是看任务生命周期和到达模式：
- 像秒杀请求、API网关转发这类毫秒级短任务 → CachedThreadPool 能快速吞吐，避免排队放大延迟
- 像定时报表生成、批量文件解析这类几百毫秒到几秒的中长任务 → FixedThreadPool 可防止线程泛滥，保障后台服务稳定性
