PriorityQueue默认按自然顺序排序，任务对象须实现Comparable或传Comparator，否则抛ClassCastException；推荐Lambda表达式定义优先级，注意整数溢出和线程安全问题。
PriorityQueue 默认比较规则不满足任务优先级需求
Java 的 PriorityQueue 默认使用自然排序（即元素实现 Comparable），但任务对象通常没有天然大小关系。直接丢进去会抛 ClassCastException 或排序错乱。
必须显式提供比较逻辑：要么让任务类实现 Comparable，要么在构造时传入 Comparator。后者更灵活，推荐用 Lambda 表达式：
PriorityQueue<task> queue = new PriorityQueue((a, b) -> Integer.compare(a.priority, b.priority));</task>
- 注意：升序排列对应“低数字优先”，即
priority=1的任务先执行；若要高优先级数字先出，改用Integer.compare(b.priority, a.priority) - 避免用
a.priority - b.priority，整数溢出会导致排序异常 -
PriorityQueue不是线程安全的，多线程场景需包装为PriorityBlockingQueue或加锁
任务对象必须可比较且状态不可变
如果任务在入队后修改了影响排序的字段（比如动态调整 priority），PriorityQueue 不会自动重排——它只在 offer()、poll() 时维护堆结构。
- 典型错误：先
queue.offer(task)，再task.priority = 0，后续poll()仍按旧值排序 - 正确做法：任务优先级应在创建时确定；如需动态调整，必须先
remove()再以新优先级重新offer() - 为防误改，建议把
priority设为final，或仅提供 getter
poll() 和 peek() 的行为差异影响调度逻辑
调度器循环中常用 poll() 取出并移除最高优先级任务，但要注意它返回 null（非空队列）或抛异常（空队列）取决于是否允许 null 元素——而 PriorityQueue 默认不允许 null。
- 调用
poll()后任务从队列消失；peek()只看不取，适合“预览+条件判断”场景（例如跳过已取消任务） - 不要用
isEmpty()+peek()替代poll()，竞态下可能peek()非空但紧接着poll()返回null - 若需原子性检查并消费，应加同步块或改用
PriorityBlockingQueue的take()
性能陷阱：频繁 remove() 导致 O(n) 开销
PriorityQueue.remove(Object) 是线性扫描，时间复杂度 O(n)，在大任务队列中频繁调用会拖慢调度器。
- 常见场景：用户取消待执行任务，你调用
queue.remove(task)—— 这比插入/弹出慢一个数量级 - 替代方案：用“懒删除”+标记字段，例如添加
boolean cancelled，poll()后检查并跳过 - 或改用支持高效删除的结构（如
TreeSet），但需自行处理重复优先级和稳定排序问题
真正难的不是怎么塞进队列，而是当任务状态随时变化、并发读写同时发生时，如何让优先级语义不被破坏。这点常被忽略。
