Някои нюанси

„Здрасти, Амиго!“

— И още няколко подробности. Нека го наречем практичен съвет.

„Да предположим, че имате метод, който чака нещо и заспива, докато дадено condition не бъде изпълнено.“

public synchronized Runnable getJob()
{
 if (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

„Документацията на Java много настойчиво препоръчва извикване на метода за изчакване в цикъл:“

public synchronized Runnable getJob()
{
 while (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

"Защо? Работата е там, че ако нишката се събуди, това не означава, че conditionто е изпълнено. Може би е имало двадесет такива спящи нишки. Всички са се събудor, но само една може да поеме задачата."

"Грубо казано, може да има "фалшиви аларми". Добрият разработчик трябва да вземе това предвид."

„Разбирам. Не е ли по-лесно просто да използвате notify?“

„Ами ако имаше повече от една задача в списъка? Notify обикновено се препоръчва да се използва в името на оптимизацията. Във всички останали случаи се препоръчва да се използва методът notifyAll.“

"ДОБРЕ."

„Но има още. Първо, може да има ситуация, при която някой наследява вашия клас, добавя свои собствени методи и също така използва wait/notifyAll. С други думи, може да има ситуация, при която независими двойки wait/notifyAll чакат на един и същ обект и не знаят един за друг. И така, Howво трябва да направите?"

„Винаги извиквайте чакане в цикъл и проверявайте дали conditionто за прекратяване на цикъла е вярно!“

„Точно. И за да стане съвсем ясно, че не можете да избягате от това, много разработчици посочват, че понякога нишките се събуждат сами. Нишки, за които е гарантирано, че няма да бъдат събудени случайно. Това изглежда е страничен ефект от оптимизацията на codeа в работеща Java машина."

„Уау. Разбрах. Без цикъл методът на изчакване не е добър.“