Java Threads on wait () теряет блокировку, но остается внутри синхронизированного блока [duplicate]

Может быть, только один работник ждет, пока условие станет истинным.

Если два или более рабочих бодрствуют (notifyAll), они должны снова проверить это условие. в противном случае все работники продолжали бы работать, хотя могут быть только данные для одного из них.

При использовании механизма wait / notify важны безопасность и жизнеспособность. Свойство безопасности требует, чтобы все объекты поддерживали согласованные состояния в многопоточной среде. Свойство liveness требует, чтобы каждая операция или вызов метода выполнялись до завершения без прерывания.

Чтобы гарантировать жизнеспособность, программы должны проверить условие цикла while перед вызовом метода wait (). Этот ранний тест проверяет, удовлетворил ли другой поток предикату условия и отправил уведомление. Вызов метода wait () после отправки уведомления приводит к неопределенной блокировке.

Чтобы гарантировать безопасность, программы должны проверить условие цикла while после возврата из метода wait (). Хотя wait () предназначен для блокировки неограниченно до получения уведомления, он все равно должен быть заключен в цикле для предотвращения следующих уязвимостей:

Thread in the middle: третий поток может получить блокировку на совместно используемый объект в течение интервала между отправленным уведомлением и возобновляющим приемом принимающего потока. Этот третий поток может изменить состояние объекта, оставив его непоследовательным. Это состояние времени проверки, времени использования (TOCTOU).

Вредоносные уведомления: случайное или злонамеренное уведомление может быть получено, когда предикат условия является ложным. Такое уведомление отменяет метод wait ().

Уведомление о недопустимости: порядок, в котором потоки выполняются после получения сигнала notifyAll (), не указан. Следовательно, несвязанный поток может начать выполнение и обнаружить, что предикат его условия выполняется. Следовательно, он может возобновить выполнение, несмотря на то, что ему необходимо оставаться бездействующим.

Подчиненные пробуждения. Некоторые реализации Java Virtual Machine (JVM) уязвимы для ложных пробуждений, которые приводят к тому, что ожидание потоков просыпается даже без уведомления.

По этим причинам программы должны проверять предикат условия после возврата метода wait (). Цикл while - лучший выбор для проверки предиката условия как до, так и после вызова wait ().

Аналогичным образом, метод await () интерфейса Condition также должен быть вызван внутри цикла. В соответствии с Java API, Условие интерфейса

При ожидании условия, допускается «ложное пробуждение», в общем, как уступка семантике базовой платформы. Это практически не влияет на большинство прикладных программ, поскольку условие всегда следует ждать в цикле, проверяя предикат состояния, которого ждут. Реализация бесплатна для устранения возможности ложных пробуждений, но рекомендуется, чтобы программисты приложений всегда предполагали, что они могут встречаться, и поэтому всегда ждут в цикле.

Новый код должен использовать java. util.concurrent.locks. Утилиты параллелизма вместо механизма wait / notify. Однако устаревший код, соответствующий другим требованиям этого правила, может зависеть от механизма ожидания / уведомления.

Пример несовместимого кода Этот пример несовместимого кода вызывает метод wait () внутри традиционного блока if и после проверки уведомления не проверяется послесловие. Если уведомление было случайным или злонамеренным, поток может просыпаться преждевременно.

synchronized (object) {
  if (<condition does not hold>) {
    object.wait();
  }
  // Proceed when condition holds
}

Соответствующее решение Это совместимое решение вызывает метод wait () из цикла while, чтобы проверить состояние как до, так и после call to wait ():

synchronized (object) {
  while (<condition does not hold>) {
    object.wait();
  }
  // Proceed when condition holds
}

Вызов метода java.util.concurrent.locks.Condition.await () также должен быть заключен в аналогичный цикл.

Ответ на документацию для Object.wait (long milis)

Нить также может проснуться без уведомления, прерывания или тайминга, так что - вызвало ложное пробуждение. Хотя это редко случается на практике, приложения должны защищать его, проверяя условие, которое должно было вызвать пробуждение потока, и продолжая ждать, если условие не будет выполнено. Другими словами, ожидания всегда должны встречаться в циклах, таких как:

 synchronized (obj) {
     while (<condition does not hold>)
         obj.wait(timeout);
     ... // Perform action appropriate to condition
 }

(дополнительную информацию по этому вопросу см. В разделе 3.2.3 в статье «Параллельные действия Дуга Ли» Программирование на Java (второе издание) »(Addison-Wesley, 2000) или Пункт 50 в« Руководстве по эффективному языку программирования Java »Джошуа Блоха (Addison-Wesley, 2001).

Я думаю, что получил ответ @Gray.

Позвольте мне перефразировать это для новичков, подобных мне, и попросить экспертов исправить меня, если я ошибаюсь.

Потребитель синхронизированный блок ::

synchronized (queue) {
    // this needs to be while
    while (queue.isEmpty()) {
       queue.wait();
    }
    queue.remove();
}

Синхронизируемый блок производителя ::

synchronized(queue) {
 // producer produces inside the queue
    queue.notify();
}

Предположим, что в данном порядке выполняется следующее:

1) потребитель №2 попадает в потребительский блок synchronized и ждет, когда очередь пуста.

2) Теперь производитель получает блокировку на queue и вставляет внутри очереди и вызывает notify ().

Теперь либо потребитель # 1 может быть выбран для запуска, который ждет блокировки queue для входа в блок synchronized в первый раз

или

потребитель # 2 можно выбрать для запуска.

3) скажем, что потребитель # 1 выбран для продолжения выполнения. Когда он проверяет условие, он будет правдой, и он remove() из очереди.

4) скажем, что потребитель №2 идет от того места, где он остановил свое выполнение (строка после wait() метод). Если условие «while» не существует (вместо условия if), он просто перейдет к вызову remove(), что может привести к возникновению исключения / неожиданного поведения.