PriorityBlockingQueue不能直接用作任务调度器，因其不支持延迟执行、不感知过期、无定时触发能力；需配合外部调度逻辑，用复合比较（先按执行时间升序，再按优先级降序），并手动实现精确等待与任务管理。
PriorityBlockingQueue 为什么不能直接当任务调度器用
它本身不支持延迟执行、不感知任务过期、也不提供定时触发能力——PriorityBlockingQueue 只是按 Comparable 或 Comparator 排序的阻塞队列，poll() 拿到的是当前堆顶元素，但不会自动等“该执行的时间到了才取”。想实现“10 秒后执行”或“优先级高且未过期的任务优先”，必须配合外部调度逻辑。
如何给任务加上可排序的优先级与执行时间
定义任务类时，把调度依据（如执行时间戳 triggerAt、业务优先级 priority）都放进比较逻辑里。常见错误是只比 priority，结果高优任务卡在队列里迟迟不执行；或者只比时间，导致紧急任务被普通定时任务压住。
推荐做法：用复合比较，先比 triggerAt（升序，越早越靠前），时间相同时再比 priority（降序，越高越靠前）：
class ScheduledTask implements Comparable<ScheduledTask> {
long triggerAt;
int priority;
Runnable action;
<pre class='brush:java;toolbar:false;'>public int compareTo(ScheduledTask o) {
int timeCmp = Long.compare(this.triggerAt, o.triggerAt);
if (timeCmp != 0) return timeCmp;
return Integer.compare(o.priority, this.priority); // 高优先级在前
}}
怎么让线程安全地“等待下一个可执行任务”
PriorityBlockingQueue 没有 poll(long, TimeUnit) 的超时版本，也不能像 DelayQueue 那样自动阻塞到 getDelay() 为 0。所以必须手动轮询 + 睡眠，但盲目 Thread.sleep(10) 浪费 CPU，sleep(1000) 又响应滞后。
可行策略：
- 每次
peek()拿到队首任务，计算距当前时间还需等多久（Math.max(0, task.triggerAt - System.nanoTime())） - 如果已到期，
poll()执行；否则用LockSupport.parkNanos(remainingNanos)精确等待 - 注意：必须在循环中检查中断状态，避免
park被唤醒后忽略新进任务 - 别用
wait()/notify——PriorityBlockingQueue内部锁不可见，无法协调
并发插入和动态优先级调整怎么处理
PriorityBlockingQueue 不支持运行中修改元素优先级（改了字段也不会自动重排序）。一旦任务入队，它的位置就固定了，除非出队再重入。
实际场景中，若需“提升某任务优先级”或“取消未执行任务”，建议：
- 用
ConcurrentHashMap<String, ScheduledTask>维护待执行任务的引用，插入时同步更新 map 和 queue - 取消任务：标记
isCancelled = true，执行前检查该 flag - 提权操作：只能
queue.remove(task)后构造新任务重新offer()（remove()是 O(n)，高频调用需评估） - 更轻量的替代：考虑
DelayQueue+ 包装器，或直接上ScheduledThreadPoolExecutor（它内部用的是DelayedWorkQueue，本质也是堆，但封装了延迟逻辑）
真正棘手的不是排序，而是“任务语义”和“队列能力”的错位——你得自己补全过期判断、重复提交防护、执行失败重试策略。这些不在 PriorityBlockingQueue 职责范围内，但线上系统缺一不可。
