PriorityQueue默认不支持动态修改优先级，因其底层为堆结构，直接修改元素字段不会触发重排，且无引用映射机制；安全做法是惰性删除+延迟重入，或改用TreeSet等替代方案。
为什么 PriorityQueue 默认不支持动态修改优先级
因为 PriorityQueue 底层是堆（heap），一旦元素入队，它的位置就由当前值决定；直接改某个元素的字段（比如任务的 priority 字段）不会触发堆重排，后续 poll() 取出的仍是旧顺序。这不是 bug，是设计使然——堆不维护元素引用映射。
常见错误现象：task.priority = 0; queue.poll() 后发现没按新优先级生效；或者用 queue.remove(task) 再重加，结果抛 ConcurrentModificationException（尤其在迭代中）。
- 真正安全的做法：用「惰性删除 + 延迟重入」，即标记任务已失效，
poll()时跳过 - 如果必须实时更新，换
TreeSet（需自定义Comparator且保证equals/hashCode与比较逻辑一致）或第三方库如Apache Commons PriorityQueue -
PriorityQueue的remove(Object)是 O(n) 查找，频繁调用会拖慢性能
如何让 PriorityQueue 支持重复任务但不同优先级
默认情况下，两个内容相同但优先级不同的任务，如果 equals() 返回 true，PriorityQueue 就认为它们是同一个对象，remove() 可能删错、contains() 判断失准。
使用场景：定时重试任务，每次失败后提升优先级（比如从 10 → 5 → 1），但任务内容（URL、参数）完全一样。
- 关键：不要只靠业务字段实现
equals()，必须把priority或唯一 ID（如taskId）纳入判断 - 示例：定义
Task类时，hashCode()和equals()都包含taskId，哪怕url和params相同，只要taskId不同，就是不同任务 - 避免踩坑：别用
new Task(url, params)当作队列元素反复创建——容易漏掉taskId，导致去重逻辑失控
PriorityQueue 的比较器陷阱：null 值和相等性处理
写自定义 Comparator 时，如果没处理好 null 或返回 0 的边界，会导致 PriorityQueue 行为异常，比如死循环、ClassCastException，甚至插入后顺序全乱。
典型错误：(a, b) -> a.priority - b.priority 在 priority 是 Integer 时可能溢出；或 a == null 时直接 NPE。
- 推荐写法：
Comparator.nullsLast(Comparator.comparingInt(t -> t.priority))，显式控制null排序位置 - 如果两个任务优先级相同，必须有次级排序（比如按
submitTime或taskId），否则堆结构不稳定，poll()结果不可预测 - 注意：Java 8+ 的 lambda 比较器不能捕获可变局部变量；若需动态权重（如按负载调整），得封装成类实例
高并发下 PriorityQueue 怎么不出错
PriorityQueue 本身不是线程安全的。多线程同时 offer() 和 poll()，大概率触发 ConcurrentModificationException 或数据丢失——它连 fail-fast 都不一定报，有时只是静默错乱。
真实场景：Web 请求触发任务提交，后台线程池持续消费，没有同步机制必崩。
- 最简单方案：用
PriorityBlockingQueue，它是线程安全的，且保留了PriorityQueue的全部语义，替换成本最低 - 慎用
Collections.synchronizedCollection(new PriorityQueue())：虽然加了锁，但复合操作（如先peek()再poll()）仍需手动同步，容易漏 - 如果需要阻塞等待（比如空队列时挂起消费者），
PriorityBlockingQueue的take()比poll()更合适
实际用的时候，最麻烦的往往不是怎么塞进去，而是怎么确认“它真按我想的顺序出来了”——建议每次 poll() 后打一行日志，输出 task.id 和 task.priority，比调试堆结构快得多。
