不能直接替换，必须在构造ThreadPoolExecutor时显式传入PriorityBlockingQueue，且需注意其不支持null、无公平性保证；队列初始化后不可变，须用new ThreadPoolExecutor(..., new PriorityBlockingQueue())创建。
PriorityBlockingQueue 能不能直接替换线程池的默认队列
不能直接替换，必须在构造 ThreadPoolExecutor 时显式传入，且需注意其不支持 null 元素、不保证公平性（相同优先级可能乱序）。
常见错误是调用 setCorePoolSize 或 prestartAllCoreThreads 后再试图替换队列——队列一旦初始化就不可变，强行替换会抛 UnsupportedOperationException。
- 必须用
new ThreadPoolExecutor(..., new PriorityBlockingQueue())构造，不能依赖Executors.newFixedThreadPool等快捷方法 -
PriorityBlockingQueue默认按自然序排序，若任务类未实现Comparable，需传入Comparator - 线程池的
allowCoreThreadTimeOut设为 true 时，PriorityBlockingQueue的阻塞特性仍有效，但空闲核心线程仍可能被回收，不影响优先级逻辑
任务类怎么写才能真正参与优先级比较
关键不是“加个字段”，而是让 PriorityBlockingQueue 在 offer/poll 时能稳定提取并比较优先级值。最简方式是让任务类实现 Comparable；更灵活的方式是用 FutureTask 包装 + 自定义 Comparator。
容易踩的坑：用 int priority 字段但没重写 compareTo，或在 compareTo 中用了可变字段（如时间戳未冻结），导致排序错乱甚至 ArrayIndexOutOfBoundsException（因为队列内部堆结构损坏）。
立即学习“Java免费学习笔记（深入）”；
- 推荐做法：任务类持有一个 final
int priority，构造时确定，compareTo只比这个字段 - 避免在
compareTo中调用可能抛异常或耗时的方法（如 DB 查询、网络请求） - 若任务需动态调整优先级，不要修改已入队任务的优先级字段——队列不会自动 re-heap，应取消原任务、新建高优任务提交
高优先级任务会不会饿死低优先级任务
会，而且很常见。因为 PriorityBlockingQueue 的 poll() 总取堆顶，只要持续有高优任务提交，低优任务可能永远等不到执行。
这不是 bug，是优先级队列的设计本质。Java 线程池本身不提供“权重轮询”或“时间片保障”机制，它只负责从队列取任务，而队列只管排序。
- 缓解方式一：限制高优任务提交速率（如用
Semaphore控制入口） - 缓解方式二：在
Comparator中引入“年龄因子”，例如(priority * 1000) - System.nanoTime()，让老任务随时间推移自动升权 - 绝对避免：在
run()里手动 sleep 或 yield 来“让权”——这破坏线程池职责分离，且无法精准控制
为什么用了 PriorityBlockingQueue 还是没看到优先级效果
大概率是任务还没进队列就被线程直接执行了。当线程池有空闲线程时，新任务会绕过队列，由空闲线程立即 execute，此时优先级队列根本没参与调度。
验证方法：把核心线程数设为 0（corePoolSize = 0），并设置 allowCoreThreadTimeOut = true，这样所有任务都必须进队列等待——这时优先级才真正起作用。
- 典型场景：小规模突发任务 + 足够空闲线程 → 优先级失效
- 真正依赖优先级的系统，通常要配合
maximumPoolSize压制（如设为 corePoolSize），逼任务排队 - 注意
RejectedExecutionHandler：当队列满+线程数达上限时，拒绝策略可能丢弃高优任务，需自定义 handler 优先处理高优任务
优先级队列只是排序工具，线程池调度逻辑本身不感知优先级。真正起作用的，是你如何让任务“不得不排队”，以及任务对象自身的可比性是否健壮。这两点漏掉任何一环，优先级就只是个摆设。
