资源饥饿指的是某些任务在长时间内始终无法获得所需的资源（CPU时间片、锁、连接、带宽等），导致工作迟迟无法推进的现象。它和死锁不同：死锁是任务互相等待彻底卡死，而饥饿往往系统还在运转，只是部分任务被无限期冷落。饥饿问题更隐蔽，监控指标可能一切正常，但个别请求的尾延迟会持续恶化。本文围绕两个核心议题展开：一是用公平队列思想让资源分配更均匀，二是识别并处理优先级反转这个造成高优先级任务饥饿的元凶。
一、资源饥饿是怎么产生的
最常见的原因是固定优先级调度策略。假设系统中有三个任务：低优先级任务A持有某个互斥锁，高优先级任务C需要这把锁，中优先级任务B既不需要锁也不阻塞，只是频繁抢占CPU。这时A拿不到CPU无法释放锁，C只能干等，而B却跑得飞快——高优先级任务反而被中优先级任务间接饿死，这就是经典的优先级反转。
另一个来源是资源分配算法本身不公平。例如网络包调度采用简单的先来先服务，遇到持续不断的大流量长连接，小流量的短请求可能永远排在后面；线程池采用无界队列且按提交顺序执行，被大量长耗时任务占满后，后续短任务全部积压。饥饿的本质是：调度策略缺少对等待时间的补偿机制，等待越久的任务没有任何优势。
二、公平队列：让等待本身产生价值
解决饥饿的主流思路是引入公平性。最基础的方案是老化技术：随着任务等待时间增加，动态提升其有效优先级。Linux早期的CPU调度就借鉴了这个思想，进程的动态优先级会随着等待CPU的时间增长而上调，最终任何任务都能排到前面，只是时间早晚问题。
更系统的方案是公平队列算法（Fair Queuing），代表包括加权公平队列WFQ以及其简化版本轮询调度。以Go语言实现一个简单的加权轮询调度器为例：
type Task struct {
Name string
Weight int // 权重越高，单位时间内获得资源的比例越大
credit int // 剩余配额，用于补偿本轮未用完的份额
}
type Scheduler struct {
tasks []*Task
index int
}
func (s *Scheduler) Pick() *Task {
for {
t := s.tasks[s.index]
s.index = (s.index + 1) % len(s.tasks)
if t.credit <= 0 {
t.credit += t.Weight
}
if t.credit > 0 {
t.credit--
return t
}
}
}这段代码的关键在于credit字段：每轮未消费完的配额会累积下来，保证某个任务即使暂时没有被选中，它应得的份额也不会消失。这种补偿机制正是对抗饥饿的核心。实际工程中，消息队列的消费者、数据库连接池分配、网络QoS限流（如令牌桶变体）都可以套用类似的思路：按来源分配配额，配额可结转，任何来源都不会被永久忽略。
需要注意的是，绝对公平往往牺牲吞吐量。轮询调度在高负载小包场景下上下文切换开销明显；JDK中Thread.yield只是提示调度器，并不保证公平。工程上通常选择折中：默认按优先级调度，但给低优先级任务保留最小份额，或者设置最长等待阈值，超时后强制提升优先级。
三、优先级反转：识别与两种经典解法
优先级反转特指这样一种情况：低优先级任务持有锁，导致高优先级任务被阻塞，而中优先级任务不受锁约束持续运行，间接延长了阻塞时间。1997年火星探路者号就因这类问题反复重启，成为教科书级案例。判断方法很简单：如果一个高优先级任务阻塞在低优先级任务持有的资源上，且系统里存在可运行的中间优先级任务，反转就发生了。
解法一：优先级继承协议。当低优先级任务持有的资源被高优先级任务请求时，临时把低优先级任务提升到请求者的优先级，让它尽快完成临界区并释放锁。释放后优先级回落。POSIX的pthread互斥锁通过PTHREAD_PRIO_INHERIT属性实现了这一协议：
pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT); pthread_mutex_t lock; pthread_mutex_init(&lock, &attr); // 低优先级线程加锁后，若有高优先级线程尝试加锁， // 内核会临时提升持锁线程的调度优先级 pthread_mutex_lock(&lock); // 临界区：尽快完成并释放 pthread_mutex_unlock(&lock);
解法二：优先级天花板协议。系统为每个锁预设一个天花板优先级（等于所有可能使用该锁的任务中的最高优先级），任务一旦获得该锁，立即被提升到天花板优先级。与继承协议相比，天花板协议在加锁瞬间就完成提升，能避免继承协议中可能出现的链式阻塞和死锁隐患，代价是要求预先知道所有任务的优先级关系，灵活性稍差，多用于实时性要求苛刻的嵌入式系统。
在应用层开发中，也有对应的实践。Java的synchronized内建锁在多数JVM实现上不提供继承机制，建议改用公平模式的ReentrantLock(true)，它按等待顺序授予锁，从根源上消除插队造成的反转；glibc的互斥锁默认实现了适应性自旋加继承逻辑；使用协程或异步框架时，应避免在持有锁的临界区内做IO操作，缩短持锁时间本身就是最有效的缓解手段。
四、工程落地清单
结合上述原理，可以在日常开发中建立一份检查清单。第一，梳理系统中所有依赖固定优先级的调度点，评估是否存在低优先级任务长期得不到资源的可能，必要时加入老化或最小份额保障。第二，审查跨优先级的共享资源访问路径，特别是中断上下文与普通线程共享的数据结构，确认底层锁是否支持优先级继承。第三，在压测中关注长尾延迟而不仅是平均值，饥饿问题的第一信号往往体现在P99延迟上。第四，线程池与队列要有界，配合拒绝策略防止任务无限积压，积压本身就是一种系统级饥饿。
总的来说，公平队列解决的是分发层面的饥饿，优先级继承与天花板协议解决的是锁竞争引发的反转，两者搭配使用，才能让系统在高并发下既保持效率又不抛弃任何一个任务。理解等待成本、为等待赋予价值，是每一个并发系统设计者必须内化的思维。