PriorityQueue 是实现任务优先级调度的最优选择，因其基于堆结构支持 O(log n) 插入与弹出，配合自定义 Comparator 可灵活定义优先级逻辑，并需搭配 ConcurrentHashMap 管理任务状态以保障并发安全。
用 PriorityQueue 实现任务优先级调度
任务管理器最核心的需求之一是按优先级执行，Java 原生集合中 PriorityQueue 是最直接的选择——它底层基于堆，插入和弹出最小（或最大）元素的时间复杂度都是 O(log n)，无需手动排序。
注意：默认构造的 PriorityQueue 按自然顺序升序排列（即“数值越小，优先级越高”），若任务优先级数字越大越紧急，必须传入自定义 Comparator：
PriorityQueuequeue = new PriorityQueue<>((t1, t2) -> Integer.compare(t2.getPriority(), t1.getPriority()));
- 别直接用
new PriorityQueue(Collections.reverseOrder())，它只对Comparable类型有效，而Task通常不实现Comparable -
PriorityQueue不保证遍历时有序，只能靠poll()或peek()获取顶部任务；遍历用stream().sorted()是错的——那会破坏队列语义且性能差 - 如果需要按时间+优先级双重排序（比如“今天到期的高优任务先执行”），
Comparator必须完整表达业务逻辑，不能只比一个字段
用 ConcurrentHashMap 存储任务状态并支持并发读写
单线程下用 HashMap 足够，但真实任务管理器常需多线程触发（如定时线程扫描、UI 线程更新状态、后台线程执行完成回调）。此时 ConcurrentHashMap 是安全又高效的选择。
关键点不是“线程安全”，而是“避免锁粒度太大”：ConcurrentHashMap 分段锁或 CAS 操作，比 Collections.synchronizedMap() 的全表锁快得多。
立即学习“Java免费学习笔记（深入）”；
- 不要用
putIfAbsent()替代业务校验——例如防止重复添加同名任务，得先get()再判断，否则竞态下仍可能插入两份 -
computeIfPresent()和merge()很适合更新任务状态（如将RUNNING改为FINISHED），它们是原子操作，不用额外同步 - 避免在循环里调用
keySet().iterator()并修改 map，可能抛ConcurrentModificationException；改用forEach()或entrySet().parallelStream()
为什么不用 LinkedList 模拟队列？
有人会想：任务就是先进先出，用 LinkedList 的 addLast()/removeFirst() 不也行？确实能跑通，但隐患明显：
-
LinkedList查找任意任务耗时O(n)，而任务管理器常需根据 ID 取消或更新某个任务——这时你不得不遍历整个链表 - 它不提供优先级能力，后续加“紧急插队”就得重构成带排序的结构，成本远高于一开始就选
PriorityQueue+ 状态 map - 内存开销比
ArrayList或数组大（每个节点存前后指针），对大量轻量任务不友好
除非你明确只要 FIFO、无取消/查询需求、且任务数极少（LinkedList 做任务容器。
任务对象设计要避开集合类的陷阱
Task 类本身不是集合，但它作为集合元素时，行为会影响整个管理器稳定性。两个硬性要求：
- 必须重写
equals()和hashCode()，尤其当任务用在ConcurrentHashMap或HashSet（比如存已取消任务 ID 集合）中；否则containsKey()永远返回false - 字段尽量不可变（
final）。比如任务创建后，ID、创建时间不应被修改；否则放进PriorityQueue后再改字段，队列内部堆结构就失效了——下次poll()可能弹出错误顺序的任务 - 如果必须支持运行时修改优先级，不要直接改字段，而是提供
reschedule(int newPriority)方法：先从队列移除旧任务（remove()），再以新优先级插入；注意remove()在PriorityQueue中是O(n)，高频修改需换方案（如用TreeSet+ 自定义比较器）
集合类不会替你管业务一致性。一个没重写 hashCode() 的 Task，放进 ConcurrentHashMap 就等于进了黑盒——查不到、删不掉、还占内存。
