scheduledthreadpoolexecutor是java中处理定时与延时任务的核心实现，基于delayedworkqueue（最小堆优先队列）实现任务按触发时间排序与阻塞等待；支持schedule（单次延迟）、scheduleatfixedrate（固定频率，无视执行耗时）和schedulewithfixeddelay（固定延迟，以上次完成为起点）三种调度模式；相比timer，它具备多线程、异常隔离、不依赖系统时间等优势，是生产环境首选。
Java线程池中处理定时与延时任务，核心靠的是 ScheduledThreadPoolExecutor，它不是普通线程池的简单扩展，而是针对时间维度做了专门设计。关键不在于“能不能做”，而在于“怎么选对方式、避免踩坑”。
延时任务：事件触发后延迟执行一次
适用于订单超时取消、支付结果延迟通知、验证码过期清理等场景。特点是单次、依赖某个动作发生的时间点（比如用户下单那一刻）。
- 调用
schedule(Runnable, delay, TimeUnit)方法，传入延迟时长即可 - 底层把任务包装成
ScheduledFutureTask，带触发时间戳，放进DelayedWorkQueue - 该队列是基于最小堆的优先队列，堆顶永远是最早到期的任务；线程取任务时会阻塞等待，直到时间到达
- 注意：如果系统时间被人为回拨，可能造成任务提前或漏执行——这点和 Timer 一样，但 ScheduledThreadPoolExecutor 多线程调度更稳
定时任务：按固定周期重复执行
适合日志归档、缓存刷新、健康检查等需要规律性运行的场景。分为两种语义，容易混淆：
-
固定频率（fixed-rate）：从任务开始时间起算，每隔指定时间就启动下一次执行，不管上次是否结束。例如
scheduleAtFixedRate(task, 0, 10, SECONDS)表示每10秒执行一次，哪怕某次执行耗时8秒，下一次仍会在第10秒准时启动 -
固定延迟（fixed-delay）：以上次任务完成时刻为起点，延迟指定时间再执行下一次。例如
scheduleWithFixedDelay(task, 0, 10, SECONDS)表示每次执行完后等10秒再启动下一轮，适合执行耗时不稳定的任务 - 两者都支持初始延迟，但周期逻辑完全不同，选错会导致任务堆积或间隔失控
为什么不用 Timer？多线程才是生产标配
Timer 看似简单，但在真实业务中问题明显：
- 单线程模型：一个任务卡住（比如网络超时），后面所有任务全被阻塞
- 异常穿透：任务抛出未捕获异常，整个 Timer 线程直接死亡，后续任务全部失效
- 无优先级：任务按提交顺序排队，不能按到期时间智能调度
- ScheduledThreadPoolExecutor 支持配置 corePoolSize，可并行调度多个任务，单个失败不影响全局，且任务按触发时间自动排序
Spring @Scheduled 默认是单线程，必须显式配线程池
很多人用 @Scheduled(fixedRate = 5000) 却发现多个任务串着跑，甚至因一个慢任务拖垮整个调度——这是因为 Spring 默认只用一个线程。
- 解决方法是在配置类中定义
TaskScheduler，指定线程数，例如：@Bean public TaskScheduler taskScheduler() { return new ThreadPoolTaskScheduler().setPoolSize(5); } - 这样所有
@Scheduled方法就会分发到线程池中并发执行，互不干扰 - 特别注意：
fixedRate在多线程下仍需评估任务实际耗时，避免线程争抢资源；cron表达式则天然支持精确时间点调度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
