线程是否有可能在 wait() 循环中饿死？答案

【问题标题】：Is it possible for a thread to starve at wait() loop?线程是否有可能在 wait() 循环中饿死？
【发布时间】：2021-09-19 12:46:02
【问题描述】：

假设我有这个方法

/*1*/    public synchronized void method1() throws InterruptedException {
    
            while (condition)
 /*2*/           wait();


  /*3*/      notify();
      }

假设，我们在第 2 行有一个 Thread 1 等待条件，所以线程 1 将处于状态 WAITING。

现在Thread 2进入，它不满足条件，所以它绕过while循环然后Thread 2在第3行调用notify，然后Thread 1应该将其状态从WAITING更改为@ 987654329@，直到Thread 2 完全退出。

现在假设，在线程 2 完全退出之前，Thread 3 是同步块之外的BLOCKED 以获取监视器。

Thread 3 是否有可能在 Thread 1 之前获得锁？ Thread 4、Thread 5等可以一样吗？在这种情况下，Thread-1 将处于饥饿状态。

这在概念上可行吗？

编辑：如果是这种情况，我该如何防止饥饿？

【问题讨论】：

简短回答：是的。你想用这个结构来达到什么目的？
嗯，没有足够的信息来给出一个可靠的建议。我们需要更多地了解condition 以及您实际尝试做的事情。也许它更容易和线程安全（er）完全不同？但要说出来，我需要知道“它”是什么。
@user16320675 或者最好颠倒逻辑。 thread 根本不应该等待。如果任何 data 还没有准备好被处理，那么它不应该被处理并放回某种队列......但是如果这适用于问题 OP 是完全未知的试图解决。
@user16320675 没错。而且你的猜测没有错。但我们所能做的就是“猜测”，直到 OP 澄清......
抱歉有歧义！我想这会回答我的问题。我只是想知道是否有任何方法可以让第一个进入阻塞状态的线程获得最高优先级。我想，在这种情况下，具有公平性的可重入锁会起作用。

标签： java multithreading wait synchronized

【解决方案1】：

如果是这种情况，我该如何防止饥饿？

您无法使用synchronized 关键字来阻止它。但是，您可以改用ReentrantLock，因为它允许“公平”锁定

private final ReentrantLock lock = new ReentrantLock(true); // fair lock
private final Condition sync = lock.newCondition();

public void method1() throws InterruptedException {
   lock.lock();
   try {
     while (condition)
       sync.await();
     sync.signal(); 
   } finally {
     lock.unlock();
   }
}

请记住，公平锁定是有代价的，您应该有真正的理由使用它

来自 JavaDoc https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html

这个类的构造函数接受一个可选的公平参数。当设置为 true 时，在争用情况下，锁有利于授予对等待时间最长的线程的访问权限。否则，此锁不保证任何特定的访问顺序。使用由许多线程访问的公平锁的程序可能会显示出比使用默认设置的程序更低的整体吞吐量（即更慢；通常要慢得多），但在获取锁和保证不会出现饥饿的情况下具有较小的时间差异。但是请注意，锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的许多线程之一可能会连续多次获得它，而其他活动线程没有进展并且当前没有持有锁。另请注意，不定时的 tryLock 方法不遵守公平设置。即使其他线程正在等待，如果锁可用，它也会成功。

【讨论】：