Java PriorityQueue不支持动态改权重，需用惰性更新：为任务加唯一ID和单调版本号，调整时新建高版本任务入队，出队时通过ConcurrentHashMap比对版本丢弃旧任务，并用组合比较器（先scheduledTime升序、再version降序）确保新任务优先。
java 的 priorityqueue 本身不支持动态修改队列中已有元素的优先级（即权重），因为其底层是基于堆的，任意位置元素权重变更后无法自动触发堆调整。要实现“动态权重调整”的后台任务调度器，核心在于绕过直接修改队列元素的限制，转而采用惰性更新 + 标记失效 + 重入队列的策略。
用唯一 ID + 版本号/时间戳标识任务状态
每个任务需携带一个不可变标识（如 long taskId）和一个可变的调度依据（如 long scheduledTime 或 int priorityLevel）。更重要的是，引入一个单调递增的版本字段（如 long version）或使用 System.nanoTime() 作为逻辑时间戳。当需要调整某任务权重时，不修改原对象，而是生成一个新任务实例（相同 taskId，新 version 和更新后的调度参数），重新加入队列。
调度器在出队时检查当前取出的任务是否为最新版本——可借助一个外部 ConcurrentHashMap<long long> latestVersion</long> 记录每个 taskId 当前有效的最大 version。若出队任务的 version < latestVersion.get(taskId)，则丢弃该任务，继续取下一个。
自定义比较器确保新任务优先于旧任务
PriorityQueue 的比较器必须同时考虑调度逻辑（如执行时间越早越优先）和版本新鲜度（新版本优先于旧版本，即使调度时间稍晚）。推荐组合排序：
- 第一优先级：按目标执行时间升序（
task.scheduledTime） - 第二优先级：按版本号降序（
-task.version），保证同时间点的新任务先执行
示例比较器：
立即学习“Java免费学习笔记（深入）”；
Comparator<ScheduledTask> cmp = Comparator.comparingLong(t -> t.scheduledTime).thenComparingLong(t -> -t.version);
线程安全与调度循环设计
PriorityQueue 本身非线程安全，应包装在 synchronized 块中，或改用 PriorityBlockingQueue（它支持阻塞插入/获取，但依然不支持动态调整）。更稳妥的做法是：
- 用
PriorityBlockingQueue<ScheduledTask>存储任务 - 用
ConcurrentHashMap<Long, AtomicLong>管理各任务最新版本号 - 调度线程循环：
poll()取任务 → 检查是否为最新版本 → 是则执行，否则继续循环 - 提供
reschedule(long taskId, long newTime)方法：更新latestVersion，构造新任务并offer()入队
避免内存泄漏与任务去重
频繁重入队列会导致历史任务对象堆积。可在任务执行完毕或确认失效后，配合弱引用或定期清理机制；更简单实用的方式是：为每个任务设置合理 TTL（如 24 小时），在比较器或出队检查中一并过滤超期的旧任务。另外，确保 ScheduledTask 正确实现 equals/hashCode（仅基于 taskId），便于后续扩展去重逻辑（如用 ConcurrentMap 缓存待调度任务，插入前先 replace）。
