Czy Java niejawnie powiadamia o oczekujących wątkach?

Question

Napisałem aplikację testową, która nigdy nie powinna się zatrzymać. Wydaje obiekt t.wait() (t jest obiektem Thread), ale nigdy nie wywołuję powiadomień. Dlaczego ten kod się kończy? Pomimo synchronizacji głównego wątku na t, wątek z wątku jest uruchamiany, więc nie blokuje tego obiektu.

public class ThreadWait { 
    public static void main(String sArgs[]) throws InterruptedException { 
     System.out.println("hello"); 
     Thread t = new MyThread(); 
     synchronized (t) { 
      t.start(); 
      Thread.sleep(5000); 
      t.wait(); 
      java.lang.System.out.println("main done"); 
     } 
    } 
} 

class MyThread extends Thread { 
    public void run() { 
     for (int i = 1; i <= 5; i++) { 
      java.lang.System.out.println("" + i); 
      try { 
       Thread.sleep(500); 
      } catch (Exception e) { 
       throw new RuntimeException(e); 
      } 
     } 
    } 
} 

Powoduje to, że wątek główny czeka 5 sekund i podczas tego czasu pracownik daje wynik. Następnie po 5 sekundach kończy się program. t.wait() nie czeka. Jeśli główny wątek nie przespałby się przez 5 sekund (komentując tę ​​linię), wówczas t.wait() faktycznie czekałby aż robot zakończy pracę. Oczywiście, tutaj jest metoda join(), ale nieoczekiwanie, wait() robi to samo co join(). Czemu?

Może JVM widzi, że ponieważ działa tylko jeden wątek, nie ma możliwości powiadomienia głównego wątku i rozwiązania zakleszczenia. Jeśli to prawda, czy jest to udokumentowana funkcja?

Mam testowanie w systemie Windows XP, Java 6.

Answer 1

Czekasz na Thread - i choć większość obiektów nie są niejawnie powiadomiony, o Thread obiekt zostanie powiadomiony, gdy wątek kończy. Jest to gdzieś udokumentowane (szukam tego ...), że powinieneś nie użyć obiektu wait/notify na obiektach Thread, ponieważ odbywa się to wewnętrznie.

Jest to dobry przykład, dlaczego najlepiej jest używać obiektu "prywatnego" do synchronizacji (i czekać/powiadamiania) - czegoś, o czym wie twój kod. Zwykle używam coś takiego:.

private final Object lock = new Object(); 

(Na ogół jednak jest to środek czyszczący do korzystania z niektórych abstrakcji wyższego poziomu świadczonych przez java.util.concurrent jeśli potrafisz Jak zauważył w komentarzach, to również dobry pomysł wdrożenia Runnable zamiast samodzielnego przedłużania Thread).

Answer 2

The JavaDoc dla wait daje odpowiedź: fałszywych wybudzeń są możliwe. Oznacza to, że JVM może zakończyć połączenie z numerem wait, kiedy tylko chce.

Dokumentacja daje nawet rozwiązanie, jeśli nie chcesz tego (co prawdopodobnie zawsze ma miejsce): włóż połączenie do wait w pętli i sprawdź, czy warunek, na który czekasz, stał się prawdziwy po każdym wznowieniu.