Java并发编程中什么是线程饥饿_问题原因与解决方法

线程饥饿是指某些线程长期处于Runnable状态却得不到CPU调度执行，比死锁更隐蔽；主因是非公平锁插队、错误依赖线程优先级及线程池配置失衡，解决需改用无锁结构或显式启用公平锁。

线程饥饿是什么？它不是死锁，但更难察觉

线程饥饿是指某个或某些线程长期得不到 CPU 时间片执行，一直处于 Runnable 状态却始终未被调度，甚至永远“等不到轮次”。它不抛异常、不卡主线程、不触发死锁检测，所以比 Deadlock 更隐蔽——你看到程序“还在跑”，但某项任务就是不动。

常见原因：synchronized 和 ReentrantLock 的不公平性陷阱

默认情况下，synchronized 和 ReentrantLock 都是**非公平锁**：新来的线程可能插队抢到锁，导致等待久的线程一直被跳过。尤其在高并发写操作场景下，读线程容易被持续压制。

• synchronized 无公平性配置选项，天生非公平
• ReentrantLock 构造时传 false（默认）即非公平；传 true 才启用公平模式，但会显著降低吞吐量
• 线程优先级（setPriority）在现代 JVM 中基本失效，别依赖它来“抢”资源

真实场景复现：低优先级日志线程被饿死

假设你用一个共享 BlockingQueue 收集日志，由低优先级线程消费。当主线程高频调用 queue.offer()，而消费者线程因调度延迟迟迟拿不到锁（比如队列内部用 synchronized 实现），就会出现日志堆积但不输出——这不是阻塞，是饥饿。

public class LogConsumer implements Runnable {
    private final BlockingQueue queue;
    public LogConsumer(BlockingQueue 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，不如让它主动退出竞争、改用事件驱动或批量处理。

• 用 LockSupport.parkNanos() 替代空循环轮询，减少调度压力
• 把长耗时任务拆成小块，中间插入 Thread.yield()（仅提示，不保证）
• 关键：改用 java.util.concurrent 中的无锁/乐观锁结构，如 ConcurrentLinkedQueue、AtomicInteger，避开锁竞争源头
• 若必须用锁，明确声明 new ReentrantLock(true)，并接受吞吐下降 10%~30%

最常被忽略的一点：饥饿往往不是单一线程的问题，而是整个线程池配置失衡——比如用 Executors.newFixedThreadPool(1) 跑混合 I/O 和计算任务，I/O 线程一阻塞，后续所有任务全饿死。