正确做法是封装带优先级字段的任务类实现Comparable，按priority或scheduledAt排序；需用PriorityBlockingQueue保证线程安全；任务取消应选DelayQueue而非PriorityQueue。
用 PriorityQueue 实现任务调度，但别直接存 Runnable
Java 自带的 PriorityQueue 是最轻量、最常用的堆实现，但它默认按自然序或 Comparator 排序，不支持按「执行时间」或「优先级数值」动态调整。直接往里塞 Runnable 会导致排序失效——因为 Runnable 没有可比性，PriorityQueue 会抛 ClassCastException 或静默乱序。
正确做法是封装一个带优先级字段的任务类：
class Task implements Comparable<Task> {
final int priority;
final Runnable action;
Task(int priority, Runnable action) {
this.priority = priority;
this.action = action;
}
public int compareTo(Task o) {
return Integer.compare(this.priority, o.priority); // 小值优先 → 最小堆
}
}-
PriorityQueue默认是最小堆，如果业务要“高优先级数字先执行”，就用Integer.compare(o.priority, this.priority) - 不要在
Task中存可变状态（如执行标记），PriorityQueue不保证修改后自动重排 - 避免用
new PriorityQueue<>(new Comparator<>(){...})匿名类写法——容易漏掉null判断，且不可序列化
任务延迟执行？别自己轮询 peek() + sleep()
常见错误是启动一个线程不断 peek() 队首，判断是否到时，再 poll() 执行。这既浪费 CPU（忙等），又不准（sleep(10) 无法精确到毫秒级）。
真正该做的是：把时间信息也纳入比较逻辑，让堆按「计划执行时间戳」排序：
立即学习“Java免费学习笔记（深入）”；
class ScheduledTask implements Comparable<ScheduledTask> {
final long scheduledAt; // 绝对时间，System.nanoTime() 或 System.currentTimeMillis()
final Runnable action;
ScheduledTask(long scheduledAt, Runnable action) {
this.scheduledAt = scheduledAt;
this.action = action;
}
public int compareTo(ScheduledTask o) {
return Long.compare(this.scheduledAt, o.scheduledAt);
}
}- 用
System.nanoTime()更适合短周期调度（纳秒级，无系统时间跳变风险）；用System.currentTimeMillis()更适合跨分钟/小时的定时场景 - 轮询间隔建议设为
Math.min(10, queue.peek().scheduledAt - now)，避免过早唤醒 - 注意：
PriorityQueue不支持 O(1) 查找任意元素，所以无法取消已入队但未执行的任务——这是它和DelayQueue的关键区别
需要取消任务？换 DelayQueue，但得实现 Delayed
如果业务明确要求「提交后还能取消」，PriorityQueue 不行，必须用 DelayQueue。它本质是支持延迟的无界阻塞队列，底层也是堆，但强制要求元素实现 Delayed 接口。
关键点不是「怎么写 getDelay()」，而是「怎么让取消生效」：
class CancelableTask implements Delayed {
private final long triggerTime;
private volatile boolean cancelled = false;
<pre class='brush:java;toolbar:false;'>CancelableTask(long delayMs) {
this.triggerTime = System.currentTimeMillis() + delayMs;
}
public long getDelay(TimeUnit unit) {
long remaining = unit.convert(triggerTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
return cancelled ? 0 : remaining;
}
public int compareTo(Delayed o) {
return Long.compare(this.triggerTime, ((CancelableTask) o).triggerTime);
}
void cancel() { this.cancelled = true; }}
-
getDelay()返回负数或 0 时，DelayQueue.take()才会返回该元素；所以取消后必须让它立刻可取，否则会卡住 -
DelayQueue不提供remove(Object)的高效实现（它是 O(n) 遍历），取消操作本身不慢，但频繁取消+插入会拖慢整体吞吐 - 别在
run()里直接调用cancel()—— 可能导致重复执行，应在取出后、执行前检查cancelled标志
并发调度多个线程消费？小心 PriorityQueue 线程不安全
PriorityQueue 是非线程安全的。多线程同时 poll() 或 offer() 会破坏堆结构，可能抛 ConcurrentModificationException，更糟的是静默数据错乱（比如高优任务被低优覆盖）。
解决方案只有两个，没有中间态：
- 用
PriorityBlockingQueue替代 —— 它是线程安全的阻塞版本，所有操作加锁，适合生产者-消费者模型 - 外层加
synchronized块包裹整个调度逻辑（例如每次只允许一个线程进调度循环），但会串行化吞吐，仅适合低频场景 - 别试图用
Collections.synchronizedCollection(new PriorityQueue())—— 它只同步单个方法，不保证复合操作（如!q.isEmpty() && q.poll()）原子性
堆结构本身不难理解，难的是边界：什么时候该用 DelayQueue 而不是自己算时间差，什么时候该接受「无法取消」来换性能，还有那个永远被忽略的点——PriorityQueue 的 iterator() 返回的不是按序遍历结果，调试时用 toString() 看到的顺序根本不能信。
