线程饥饿是指某些线程长期处于Runnable状态却得不到CPU调度执行，比死锁更隐蔽；主因是非公平锁插队、错误依赖线程优先级及线程池配置失衡，解决需改用无锁结构或显式启用公平锁。
线程饥饿是什么？它不是死锁，但更难察觉
线程饥饿是指某个或某些线程长期得不到 CPU 时间片执行，一直处于 Runnable 状态却始终未被调度，甚至永远“等不到轮次”。它不抛异常、不卡主线程、不触发死锁检测，所以比 Deadlock 更隐蔽——你看到程序“还在跑”，但某项任务就是不动。
常见原因：synchronized 和 ReentrantLock 的不公平性陷阱
默认情况下，synchronized 和 ReentrantLock 都是**非公平锁**：新来的线程可能插队抢到锁，导致等待久的线程一直被跳过。尤其在高并发写操作场景下，读线程容易被持续压制。
-
synchronized无公平性配置选项，天生非公平 -
ReentrantLock构造时传false（默认）即非公平；传true才启用公平模式，但会显著降低吞吐量 - 线程优先级（
setPriority）在现代 JVM 中基本失效，别依赖它来“抢”资源
真实场景复现：低优先级日志线程被饿死
假设你用一个共享 BlockingQueue 收集日志，由低优先级线程消费。当主线程高频调用 queue.offer()，而消费者线程因调度延迟迟迟拿不到锁（比如队列内部用 synchronized 实现），就会出现日志堆积但不输出——这不是阻塞，是饥饿。
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
public class LogConsumer implements Runnable {
private final BlockingQueue<String> queue;
public LogConsumer(BlockingQueue<String> q) {
this.queue = q;
// ❌ setPriority(Thread.MIN_PRIORITY) 无效且误导
}
public void run() {
while (!Thread.currentThread().isInterrupted()) {
try {
String log = queue.poll(1, TimeUnit.SECONDS); // 可能长期为 null
if (log != null) System.out.println(log);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}
}
解决思路：换结构，不靠“等调度”
与其让线程等 CPU，不如让它主动退出竞争、改用事件驱动或批量处理。
立即学习“Java免费学习笔记（深入）”；
- 用
LockSupport.parkNanos()替代空循环轮询，减少调度压力 - 把长耗时任务拆成小块，中间插入
Thread.yield()（仅提示，不保证） - 关键：改用
java.util.concurrent中的无锁/乐观锁结构，如ConcurrentLinkedQueue、AtomicInteger，避开锁竞争源头 - 若必须用锁，明确声明
new ReentrantLock(true)，并接受吞吐下降 10%~30%
最常被忽略的一点：饥饿往往不是单一线程的问题，而是整个线程池配置失衡——比如用 Executors.newFixedThreadPool(1) 跑混合 I/O 和计算任务，I/O 线程一阻塞，后续所有任务全饿死。
