FixedThreadPool适合CPU密集型任务，线程数固定且资源可控，但遇IO阻塞易导致队列堆积和拒绝异常；CachedThreadPool适合短平快异步任务，但高并发下易OOM；SingleThreadExecutor仅保证串行执行，不保证线程安全；ScheduledThreadPoolExecutor是唯一可靠的定时方案，需注意任务幂等性和延时策略选择。
FixedThreadPool 适合 CPU 密集型任务，但别硬塞 IO 操作
它用固定数量的线程反复处理任务，线程数设多少，就一直维持多少个活跃线程。好处是资源可控，不会因为突发请求把系统拖垮；坏处是如果任务里夹着 Thread.sleep(1000) 或 httpClient.execute() 这类阻塞调用，线程就被卡住，队列会越堆越长。
常见错误现象：RejectedExecutionException 频发，或者监控显示线程利用率长期 100%，但吞吐没上去。
使用场景：图像缩放、JSON 解析、加解密计算等纯内存操作。
实操建议：
- 线程数通常设为
Runtime.getRuntime().availableProcessors()或 +1 - 避免在任务里做数据库查询、HTTP 调用、文件读写
- 如果必须混合 IO，改用
ThreadPoolExecutor自定义，配更大的队列和合理的拒绝策略
CachedThreadPool 适合短平快的异步通知，但绝不用于定时或长耗时任务
它按需创建线程，空闲 60 秒自动回收，核心线程数为 0，最大线程数是 Integer.MAX_VALUE。表面看很“弹性”，实际等于把线程创建压力甩给 JVM 和 OS。
常见错误现象：突然大量请求进来，瞬间创建几百个线程，触发 OutOfMemoryError: unable to create new native thread；或者 GC 压力陡增，响应延迟翻倍。
使用场景：RPC 调用后的日志记录、MQ 消息消费后的轻量回调、用户行为埋点上报。
实操建议：
- 只用于执行时间稳定在几十毫秒内、无外部依赖的任务
- 绝对不要传入含
while(true)、wait()或长 sleep 的Runnable - 线上环境建议直接禁用，改用带界线程池（如
new ThreadPoolExecutor(2, 20, 60L, TimeUnit.SECONDS, new SynchronousQueue())）
SingleThreadExecutor 不等于“安全”，只是串行执行
它本质是 1 核心线程 + 无界队列的 ThreadPoolExecutor，所有任务排队按顺序跑。很多人误以为用了它就不用加锁了——错。它只保证执行顺序，不保证对象状态可见性或原子性。
常见错误现象：多个任务修改同一个 ArrayList，结果数据丢失或 ConcurrentModificationException；或者共享一个非线程安全的 SimpleDateFormat，解析出错。
使用场景：维护单个资源的状态机（如设备连接状态切换）、写本地日志文件、刷新某个缓存值。
实操建议：
- 任务内部仍需对共享变量做同步（
synchronized或AtomicInteger） - 避免在任务中阻塞等待另一个任务完成（比如
future.get()），否则整个队列卡死 - 注意它的无界队列：如果任务执行变慢，队列会无限增长，OOM 风险高
ScheduledThreadPoolExecutor 是唯一靠谱的定时方案，Executors.newScheduledThreadPool() 只是糖衣
Executors.newScheduledThreadPool(n) 返回的就是 ScheduledThreadPoolExecutor 实例，别被名字骗了——它不是“增强版 Fixed”，而是专为定时/周期任务设计的子类，底层用的是延迟队列（DelayedWorkQueue），支持 scheduleAtFixedRate 和 scheduleWithFixedDelay 两种语义。
常见错误现象：用 FixedThreadPool + Timer 混搭，结果 Timer 线程挂了整个定时逻辑失效；或误用 scheduleAtFixedRate 执行耗时任务，导致后续任务堆积甚至并发执行。
使用场景：心跳检测、缓存预热、定时拉取配置、清理临时文件。
实操建议：
- 周期任务体必须是幂等的，或自带防重逻辑（比如检查上一次是否还在运行）
- 优先选
scheduleWithFixedDelay，它等前一次执行完再算下一次延时，更可控 - 线程数至少为 1，但别设太大——多数定时任务不需要并发，设多了反而抢资源
真正难的不是选哪个池，是搞清每个任务到底在等什么：等 CPU？等磁盘？等网络？等锁？等信号？选错池子，问题不会消失，只会换个姿势报错。
