ScheduledThreadPoolExecutor 的延时执行基于“时间感知+延迟队列+主动阻塞等待”，使用纳秒级绝对时间戳、DelayedWorkQueue最小堆排序及LockSupport.parkNanos精确阻塞，不依赖系统时钟，调度层不受时间回拨影响。
ScheduledThreadPoolExecutor 的延时执行机制，核心在于“时间感知 + 延迟队列 + 主动阻塞等待”，不是靠轮询或 busy-wait，而是高效、低开销的被动唤醒模型。
延迟任务怎么封装？
调用 schedule(Runnable, delay, unit) 时，框架会把原始任务包装成 ScheduledFutureTask 对象，这个对象携带三个关键信息：
- 原始任务逻辑（Runnable 或 Callable）
- 触发时间戳（triggerTime = System.nanoTime() + delayInNanos）
- 唯一序号（用于相同触发时间下的 FIFO 排序）
这个时间戳是纳秒级绝对时间，与系统时钟无关——它只依赖当前时刻加延迟量，后续判断是否到期全靠比对当前纳秒时间。
任务怎么排队和排序？
所有 ScheduledFutureTask 都进入 DelayedWorkQueue，这是一个基于最小堆（Min-Heap）实现的优先队列：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 堆顶永远是 triggerTime 最早的任务
- 插入和取任务的时间复杂度都是 O(log n)，适合大量定时任务场景
- 队列本身不主动检查时间，只提供“谁该最先执行”的排序能力
注意：DelayedWorkQueue 是无界队列，不会因容量满而拒绝任务；它也不支持普通 poll/take 语义，而是重写了 getDelay() 方法返回剩余纳秒数，作为线程阻塞依据。
线程怎么知道什么时候该执行？
工作线程从队列取任务时，并非立即返回，而是执行类似这样的逻辑：
- 取出堆顶任务，调用其 getDelay(NANOSECONDS)
- 若返回值 ≤ 0 → 任务已到期，直接执行
- 若返回值 > 0 → 调用 LockSupport.parkNanos(remainingNanos) 精确阻塞，直到接近到期时刻
这种机制避免了空转消耗 CPU，也无需依赖系统时间轮询。一旦任务到期或被外部取消，线程会被精确唤醒，而非靠超时兜底。
为什么系统时间回拨会影响它？
虽然 triggerTime 是相对计算得出的，但最终判断是否到期仍依赖 System.nanoTime() —— 它不受系统时钟修改影响，是单调递增的高精度计时器。真正受影响的是 System.currentTimeMillis()，而 ScheduledThreadPoolExecutor 并不使用它做调度判断。
不过，如果你在任务体内部用了 currentTimeMillis() 做业务逻辑（比如生成日志时间戳、计算超时阈值），那这部分仍可能因系统时间跳变出错。调度层本身是安全的。
