"Hai, Amigo!"

"Dan beberapa butiran lagi. Mari kita panggil ia nasihat praktikal."

"Anggaplah anda mempunyai kaedah yang menunggu sesuatu dan tertidur sehingga keadaan dipenuhi."

Jika koleksi kosong, maka kita tunggu
public synchronized Runnable getJob()
{
 if (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

"Dokumentasi Java dengan sangat mendesak mengesyorkan memanggil kaedah tunggu dalam gelung:"

Jika koleksi kosong, maka kita tunggu
public synchronized Runnable getJob()
{
 while (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

"Kenapa? Masalahnya ialah jika benang itu bangun, itu tidak bermakna bahawa syaratnya berpuas hati. Mungkin ada dua puluh benang tidur seperti itu. Semuanya bangun, tetapi hanya satu yang boleh mengambil tugas itu."

"Secara kasarnya, mungkin terdapat 'penggera palsu'. Pembangun yang baik mesti mengambil kira perkara ini."

"Saya faham. Bukankah lebih mudah menggunakan notify sahaja?"

"Nah, bagaimana jika terdapat lebih daripada satu tugasan dalam senarai? Notify biasanya disyorkan untuk digunakan demi pengoptimuman. Dalam semua kes lain, disyorkan untuk menggunakan kaedah notifyAll."

"OKEY."

"Tetapi ada lagi. Pertama, mungkin terdapat situasi di mana seseorang mewarisi kelas anda, menambah kaedah mereka sendiri, dan juga menggunakan wait/notifyAll. Dalam erti kata lain, mungkin terdapat situasi di mana pasangan tunggu/notifyAll bebas menunggu pada objek yang sama dan tidak mengenali antara satu sama lain. Jadi apa yang perlu kamu lakukan?"

"Sentiasa panggil tunggu dalam gelung dan semak sama ada keadaan penamatan gelung adalah benar!"

"Betul. Dan untuk menjelaskan bahawa anda tidak boleh lari daripada perkara ini, ramai pembangun menunjukkan bahawa kadangkala benang terjaga dengan sendirinya. Benang yang dijamin tidak akan terjaga secara tidak sengaja. Ini nampaknya kesan sampingan pengoptimuman kod dalam menjalankan mesin Java."

"Wah. Faham. Tanpa gelung, kaedah menunggu tidak bagus."