Néhány árnyalat

– Szia Amigo!

– És még néhány részlet. Nevezzük gyakorlati tanácsnak.

"Tegyük fel, hogy van egy módszere, amely vár valamire, és addig alszik el, amíg egy feltétel teljesül."

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

 return jobs.remove(0);
}

"A Java dokumentáció nagyon kitartóan javasolja a várakozási metódus ciklusban történő meghívását:"

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

 return jobs.remove(0);
}

– Miért?

"Nagyjából véve, előfordulhatnak "téves riasztások". Egy jó fejlesztőnek ezt figyelembe kell vennie."

"Értem. Nem egyszerűbb az értesítést használni?"

"Nos, mi van akkor, ha több feladat is szerepel a listában? A Notify-t általában az optimalizálás kedvéért javasolják használni. Minden más esetben a notifyAll metódus használata javasolt."

"RENDBEN."

"De van még több is. Először is előfordulhat olyan helyzet, amikor valaki örökli az osztályodat, hozzáadja a saját metódusait, és a wait/notifyAll-t is használja. Más szóval, előfordulhat olyan helyzet, amikor a független várakozás/értesítés pár ugyanazon az objektumon várakozik. és nem tudnak egymásról. Szóval mit kell tenned?"

"Mindig hívja a várakozást hurokban, és ellenőrizze, hogy a hurok lezárási feltétele igaz-e!"

"Helyes. És hogy egyértelművé tegyük, hogy ezt nem lehet elkerülni, sok fejlesztő rámutat arra, hogy a szálak néha maguktól felébrednek. Olyan szálak, amelyek garantáltan nem ébrednek fel véletlenül. Úgy tűnik, hogy ez a kódoptimalizálás mellékhatása. Java gépen fut."

"Hú. Értem. Hurok nélkül a várakozási módszer nem jó."