理解 ScheduledThreadPoolExecutor 的堆排序原理，关键不在“堆怎么实现”，而在于“为什么必须用最小堆”以及“任务时间变化时堆如何维持正确性”。它的核心不是数据结构炫技，而是精准控制任务执行顺序。
DelayedWorkQueue 本质是最小堆，不是普通队列
DelayedWorkQueue 不是 FIFO 队列，它内部用数组模拟完全二叉树，按任务的 time 字段（纳秒级触发时间戳） 构建最小堆：堆顶永远是 最早该被执行的任务。如果两个任务 time 相同，则按 sequenceNumber 排序，保证插入顺序不被打破。
每次添加新任务（如调用 schedule()），都会调用 siftUp()，从尾部上浮，逐层与父节点比较并交换，直到满足堆序（父 ≤ 子） 每次取出堆顶任务执行后，若为周期任务，会更新其 time 字段（比如加 period 或设为 now + delay），再调用 siftDown() 重新下沉，确保堆结构仍有效 线程调用 take() 时，若堆顶 time > 当前时间，就阻塞等待；只有 time ≤ 当前时间，才允许出队
延迟任务（schedule）：一次入堆，一次执行
提交一个延迟 5 秒的任务，会被封装成 ScheduledFutureTask，其中 time = System.nanoTime() + 5_000_000_000。这个 time 就是它在堆里的唯一排序依据。
入堆即完成排序，无需额外维护 线程从队列取任务时，只检查堆顶是否到期；未到期就 park 等待，不轮询、不忙等 执行完即结束，不会重入队
周期任务：每次执行后动态重排堆
周期任务的调度逻辑藏在 run() 方法里——执行完不返回，而是计算下一次 time，再把自己塞回 DelayedWorkQueue。这一步触发了堆的二次调整。
scheduleAtFixedRate：下一次 time = 上次原始触发时间 + period → 可能堆积（比如任务超时，下次仍按原计划触发，“追赶模式”） scheduleWithFixedDelay：下一次 time = 当前系统时间 + delay → 严格串行，无追赶 无论哪种，更新 time 后都需重新 siftDown，因为该任务可能已不在合适位置；堆不能自动感知字段变更，必须显式修复
time 字段是排序唯一依据，但不是静态值
ScheduledFutureTask 的 time 是 volatile long，初始由 triggerTime() 计算得出，后续由 setNextRunTime() 动态更新。堆本身不监听这个字段变化，所以每次修改后必须手动调用 siftDown() —— 这正是 DelayedWorkQueue 在周期任务场景下保持时效性的底层保障。
没有这个机制，任务就会按旧时间排队，导致严重延迟或跳过执行。
评论(0)