选ScheduledExecutorService而非Timer，因其基于线程池，单任务异常不影响其他任务，且支持并发调度；Timer单线程且异常会导致全部任务终止。
为什么不用Timer而选ScheduledExecutorService
因为 Timer 是单线程执行，一个任务抛出未捕获异常会导致后续所有任务被取消；而 ScheduledExecutorService 基于线程池，单个任务失败不影响其他任务，且支持多线程并发调度。
常见错误现象：Timer 中的 scheduleAtFixedRate 在任务执行超时时会“堆积”触发（即跳过未执行的周期），但开发者误以为它会自动补偿——其实不会，而且一旦异常，整个调度就停了。
- 使用场景：需要长期稳定运行的后台轮询、心跳检测、缓存刷新
- 性能影响：默认
Executors.newScheduledThreadPool(1)仍是单线程，如需并行多个定时任务，必须显式指定大于1的线程数 - 兼容性：JDK 5+，无额外依赖
如何正确创建和关闭ScheduledExecutorService
不能只调用 shutdown() 就完事——它只是停止接收新任务，正在运行的任务仍会执行完，但定时任务可能卡在下一次调度前就被中断。必须配合 awaitTermination() 等待完成，或用 shutdownNow() 强制中断。
容易踩的坑：shutdownNow() 会尝试中断正在执行的线程，但若任务里没响应中断（比如没检查 Thread.interrupted() 或没处理 InterruptedException），线程实际不会退出。
立即学习“Java免费学习笔记（深入）”；
- 推荐写法：用
try-finally包裹任务逻辑，并在 finally 中调用shutdown() - 优雅关闭步骤：
executor.shutdown(); try { if (!executor.awaitTermination(10, TimeUnit.SECONDS)) { executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); } - 避免直接用
Executors.newSingleThreadScheduledExecutor()返回的实例——它不支持setRemoveOnCancelPolicy(true)，导致大量已取消但未执行的任务堆积在队列中
schedule、scheduleAtFixedRate、scheduleWithFixedDelay 的区别
这三个方法决定“什么时候触发下一次”，但语义完全不同，选错会导致任务节奏失控。
-
schedule(Runnable, delay, TimeUnit)：只执行一次，延迟delay后运行 -
scheduleAtFixedRate(Runnable, initialDelay, period, TimeUnit)：从initialDelay开始，每period执行一次，**固定速率**——不管上一次是否执行完，到点就触发（可能并发） -
scheduleWithFixedDelay(Runnable, initialDelay, delay, TimeUnit)：从initialDelay开始，每次执行完后等待delay再执行下一次，**固定延迟**——绝对不并发
举例：设 period = delay = 5s，任务本身耗时 6s：
-
scheduleAtFixedRate会立即在第5秒启动第二次执行（与第一次重叠） -
scheduleWithFixedDelay则在第11秒（6s执行 + 5s延迟）才开始第二次
如何取消某个已提交的定时任务
靠 ScheduledFuture.cancel(boolean mayInterruptIfRunning)，但返回值必须检查——如果任务已开始执行或已完成，cancel() 返回 false，此时再调用无效。
容易忽略的细节：同一个 ScheduledFuture 实例只能取消一次；多次调用 cancel() 不会报错，但也不会重复生效。
- 保存引用：务必把
scheduleXxx()返回的ScheduledFuture存起来，比如放进Map<string scheduledfuture>></string>，否则无法定向取消 - 取消后清理：调用
cancel(true)后，建议将该 future 从容器中移除，避免内存泄漏 - 注意线程安全：如果多个线程可能同时取消/查询同一任务，容器需加锁或用
ConcurrentHashMap
复杂点在于：任务内部如果用了阻塞 I/O（如 Socket.read()）、无限循环且未检查中断状态，cancel(true) 也无法真正终止它——这时候得靠任务自己响应中断或加超时控制。
