PriorityQueue.clear() 能清空队列元素但不重置容量、comparator 或释放内存，底层数组仍保留且未置null（JDK7）或置null（JDK8+），多线程需同步，任务执行中不受影响，安全清空需结合新建实例、drainTo、cancel及加锁。
clear() 能否真正清空 PriorityQueue 的任务队列？
PriorityQueue.clear() 确实会移除所有元素，但“清空”不等于“重置状态”——它不会重置内部堆结构的容量、不会改变 comparator，也不会影响后续插入时的排序行为。调用后队列长度为 0，但底层数组（queue 数组）仍保留原有容量，只是所有索引位置被设为 null（对引用类型）或默认值（对基本类型包装类）。这意味着内存未立即释放，且下次 offer() 可能触发扩容前的复用。
调用 clear() 后为什么任务没真正“消失”？
常见误判场景：你清空了队列，但仍有任务在执行或被重复提交。这通常不是 clear() 失效，而是逻辑层未同步清理关联状态。比如：
- 任务对象本身持有外部引用（如监听器、回调函数），
clear()只断开了队列引用，GC 不会立刻回收 - 你用
PriorityQueue<task></task>，但Task实现了自定义compareTo()，而某些字段在清空后未重置，导致后续插入时比较异常 - 多个线程共用该队列，
clear()未加锁，清空中途有新任务offer()进来，造成“看似清空失败”
如何安全地清空并重置 PriorityQueue 的运行状态？
单纯调用 clear() 不够。你需要组合操作，覆盖典型使用场景：
- 若需彻底释放内存并重置容量：新建实例，
queue = new PriorityQueue(initialCapacity, comparator)；避免复用旧数组 - 若必须复用实例（如 Spring Bean 单例），清空前先
drainTo(new ArrayList())获取副本做审计，再clear()，最后显式置空可能持有的外部资源（如task.cancel()） - 多线程下务必同步：用
synchronized(queue) { queue.clear(); }，或改用线程安全替代品如PriorityBlockingQueue（但注意它没有clear()的批量原子性，仍需同步） - 检查
comparator是否依赖外部可变状态（如时间戳、配置开关），如有，清空后应重新设置或重建队列
clear() 的性能和兼容性要注意什么？
clear() 时间复杂度是 O(n)，因为要逐个置空数组元素（JDK 8+ 对引用类型会写 null 防止内存泄漏）；它不触发堆重构，所以比反复 poll() 快得多。但注意：
立即学习“Java免费学习笔记（深入）”；
- JDK 7 中
clear()不置空数组，可能导致 GC 延迟 —— 升级到 JDK 8+ 是硬性前提 - 如果队列里存的是
Runnable或Future，clear()不会取消执行中的任务，只移除待调度项 - 子类如
DelayedQueue（非标准类）可能重写了clear()，务必查文档；标准PriorityQueue行为是可靠的
真正难的从来不是调用 clear() 这一行代码，而是确认所有任务引用是否已脱离生命周期管理，以及并发上下文里“清空”这个动作是否落在了正确的执行窗口。
