PriorityQueue.remove() 效果差是因为需 O(n) 线性查找+O(log n) 堆调整，且无法按 deadline 索引；推荐用 DelayQueue、标记过滤或时间分片索引替代。
PriorityQueue.remove() 不适合用于高效清理过期任务，因为它在内部需要遍历整个队列（时间复杂度 O(n)），且会破坏堆结构——调用后需重新堆化，而 PriorityQueue 本身不保证 remove 后的顺序或性能稳定性。实际场景中，应避免依赖它做高频、批量的过期清理。
为什么 remove() 在任务队列中效果差
PriorityQueue 底层是小顶堆（默认），只保证队首元素最小，其余元素无序。remove(Object o) 必须线性扫描查找目标，再执行“替换末尾 + 下滤/上滤”来恢复堆性质。对一个含数千任务的队列，每次 remove 都可能触发 O(n) 查找 + O(log n) 调整，频繁调用会导致明显延迟和 CPU 消耗。
更关键的是：任务是否过期，通常依赖当前时间与任务 deadline 比较，而 PriorityQueue 无法按 deadline 快速索引——它只按优先级排序，不是按时间索引。
推荐替代方案：延迟队列 + 懒清理
用 DelayedQueue（如 DelayQueue）替代普通 PriorityQueue，它是专为定时任务设计的无界阻塞队列，内部基于可重入堆，支持自然到期提取：
- 任务类实现
Delayed接口，重写getDelay(TimeUnit)返回剩余延迟； - 调用
poll()只取已到期任务，take()则阻塞等待到期； - 过期任务自动“就绪”，无需手动 remove；未到期任务始终沉在队列底部，不参与干扰。
若必须用 PriorityQueue：用标记+过滤代替 remove
保持队列只增不删，清理逻辑后置：
- 每个任务对象增加
boolean expired字段或用原子状态标记； - 消费时（如
poll()后）先检查task.isExpired(System.currentTimeMillis())； - 若过期，直接丢弃并继续
poll()，直到拿到有效任务； - 定期（如每 100 次消费后）调用一次
removeIf(task -> task.isExpired())做批量惰性清理（Java 8+ 支持，仍 O(n)，但频次可控）。
进阶：自建时间分片索引（适合高吞吐场景）
将任务按到期时间哈希到多个子队列（如按秒/毫秒桶），维护一个主时间指针：
- 插入时根据 deadline 计算所属时间桶，放入对应
ConcurrentLinkedQueue； - 后台线程按时间推进，只清理当前已过期桶中的全部任务；
- 查询最近任务时，从当前桶开始向后扫描，跳过空桶，找到首个非空桶取头结点。
这种方式把 O(n) 清理摊平为 O(1) 桶切换 + O(k) 单桶遍历（k 是该秒内任务数），扩展性和实时性更好。
