PriorityBlockingQueue易引发任务饥饿，因其仅按静态优先级取任务，高优任务持续涌入时低优任务长期滞留队尾；且无等待衰减机制，老任务优先级不提升，空闲线程也只取队首任务，导致低优任务无限延后。
PriorityBlockingQueue 本身是为任务排序设计的，但它在线程池中用得不当时，反而会让部分任务“永远排在后面”，形成任务饥饿。
它不是队列本身有问题，而是“优先级逻辑”和“执行机制”不匹配导致的。
为什么 PriorityBlockingQueue 容易引发任务饥饿？
只按优先级排序，不保证公平性
队列每次取任务，都挑优先级最高的那个。如果高优先级任务源源不断提交（比如监控心跳、告警推送），低优先级任务（如日志归档、报表生成）就会一直被压在底部，迟迟得不到执行。没有等待时间衰减机制
一个低优先级任务在队列里等了10分钟，它的优先级不会自动提升。而新来的高优任务一到就插队——老任务越等越靠后。线程池工作线程只从队首取任务
即使池中有空闲线程，它们也只会拿队列头的任务。只要头部始终是高优任务，低优任务就只能干等，哪怕它已排队半小时。
典型饥饿场景举例
-
电商系统中：
-
PRIORITY_HIGH：支付回调验证（每秒几十个） -
PRIORITY_LOW：用户行为埋点上报（每分钟一批）
→ 埋点任务可能连续几小时无法出队。
-
-
IoT平台中：
-
ALERT_PRIORITY：设备离线告警（高频、短任务） -
SYNC_PRIORITY：设备配置批量同步（低频、长任务）
→ 同步任务反复被跳过，最终超时失败。
-
如何缓解这种饥饿？
✅ 给低优先级任务设置“最低保障时间窗”
比如每5分钟强制调度一次最低优先级队列中的最老任务，不管优先级多低。✅ 组合使用多个线程池
高优任务走专用池（小队列+快速响应），低优任务走独立池（大间隔轮询+宽松超时）。✅ 动态调整优先级（优先级老化）
提交时记录时间戳，取任务前按等待时长加权提升优先级：effectivePriority = basePriority + log2(waitSeconds)✅ 避免把“业务重要性”和“技术优先级”完全等同
真正关键的后台任务（如数据库备份）未必需要最高优先级，但必须有执行兜底机制。
任务饥饿不是队列不工作，而是它太“听话”——只认优先级，不看等待时长、不问业务语义、也不管是否已经饿太久。用好它，得靠人在外面补一层调度逻辑。
