ScheduledExecutorService 能稳替 Timer 因其是带调度能力的线程池，支持任务排队、时间计算、线程复用与异常兜底；而 Timer 仅单线程裸调度，异常会导致后续任务永久失效。
为什么 ScheduledExecutorService 能稳替 Timer
因为 ScheduledExecutorService 不是“另一个定时器”，而是带调度能力的线程池——它把任务排队、时间计算、线程复用、异常兜底全包了，而 Timer 只是单线程+裸调度，连异常都接不住。
- Timer 内部只有一条线程，一个
TimerTask抛NullPointerException或卡死 2 小时，所有后续任务永久失效 - ScheduledExecutorService 每个任务在独立线程（或线程池内可复用线程）中运行，异常被线程池捕获，不影响其他任务
- Timer 基于系统绝对时间（比如“明天凌晨 2:00”），系统时钟被 NTP 校准或手动调快/慢，任务就可能提前或跳过；
ScheduledExecutorService基于相对延迟（“现在起 5 秒后执行”），完全免疫时钟漂移
scheduleAtFixedRate 和 scheduleWithFixedDelay 到底怎么选
这两个方法看着像，行为却差很远——选错会导致任务扎堆或严重滞后，尤其在线上长耗时任务里特别明显。
-
scheduleAtFixedRate：按“固定周期”推进，不管上次任务是否结束。比如 period=5s，但某次任务跑了 8s，那下一次会立刻触发（不等），连续补上漏掉的轮次 -
scheduleWithFixedDelay：严格等“上一次执行完 + delay 时间”才启动下一次。哪怕任务跑 20 分钟，下一次也只在它结束后再等 5 秒，绝不会堆积 - 报表生成、对账类任务建议用
scheduleWithFixedDelay，避免并发写冲突或资源打满；心跳上报、状态轮询这类轻量高频任务可用scheduleAtFixedRate
怎么安全地替换老项目里的 Timer
不是简单把 new Timer() 换成 Executors.newScheduledThreadPool(3) 就完事——线程池生命周期和关闭逻辑必须显式管理，否则容易内存泄漏或 JVM 无法退出。
- 别用
Executors.newScheduledThreadPool(n)创建无名池，要用new ScheduledThreadPoolExecutor(corePoolSize, threadFactory, handler)，自定义ThreadFactory打上业务前缀（如 “report-scheduler-”），方便排查 - 务必在应用 shutdown 时调用
scheduler.shutdown()+scheduler.awaitTermination()，否则未完成任务会被静默丢弃 - 原来 Timer 中用
timer.cancel()+task.cancel()控制启停，现在要保存每个ScheduledFuture实例，用future.cancel(true)主动中断正在运行的任务
返回值 Future 有什么实际用处
Timer.schedule() 返回 void，你根本不知道任务是否真跑完了；而 ScheduledExecutorService.schedule() 返回 ScheduledFuture，能真正掌控任务状态。
- 调用
future.isDone()或future.get(timeout, unit)可判断任务是否超时失败，适合关键路径做降级（比如定时拉取配置失败时 fallback 到本地缓存） - 用
future.cancel(true)可中断阻塞中的 IO 或 sleep，比 Timer 的 cancel 粗暴终止更可控 - 注意：只有
schedule(Callable)才能拿到执行结果；schedule(Runnable)的get()永远返回 null，别误以为能取值
线程池大小不是越大越好，也不是拍脑袋定 1、2、5；得看任务类型——IO 密集型可设为 CPU 核数 × 2 以上，CPU 密集型建议 ≤ 核数。这点常被忽略，结果要么线程太多拖垮 GC，要么太少导致调度积压。
