Running wait() su un'istanza di Thread da main() in Java

Question

Sto giocando con la versione a tempo di wait() in java.lang.Object e ho osservato che agisce in modo diverso in due diversi scenari.

Scenario1: Utilizzando la definizione di default di run() nella Discussione

public static void main (String[] args) throws InterruptedException { 
    Thread t = new Thread();  
    t.start(); 
    System.out.print("X"); 
    synchronized(t) { t.wait(10000);} 
    System.out.print("Y"); 
} 

Domande su scenario1: sto sperimentando un ritardo tra X e Y. E 'questa attesa perché sto chiamando() da main (anche se, su t) e quindi lo stack di chiamate del thread principale viene utilizzato, piuttosto che quello del secondo thread?

Scenario2:Sottoclasse Filettatura al volo per eseguire l'override di esecuzione() per stampare qualcosa.

public static void main (String[] args) throws InterruptedException { 
    Thread t = new Thread() {public void run() 
        {System.out.print("I am the second thread.");}}; 
    t.start(); 
    System.out.print("X"); 
    synchronized(t) { t.wait(10000);} 
    System.out.print("Y"); 
} 

Domande su scenario2: NON sto sperimentando ogni ritardo a tutti! Cosa è cambiato solo perché ho eseguito overridden()? Ora, ogni volta che eseguo il programma, stampa immediatamente "XI am the second thread.Y" senza alcun ritardo, qualunque cosa! Dove è andato a finire l'effetto di wait()?

Answer 1

Il explanation about how the thread finishing sends a notifyAll è pertinente e corretto, +1 da me. Proverò ad aggiungere alcune informazioni sul perché questo è rilevante.

Quando si chiama

synchronized(t) { t.wait(10000);} 

nel thread principale, è il filo conduttore che fa l'attesa. t è il monitor su cui è in attesa il thread principale. La tua aspettativa che questo dovrebbe rendere il thread t andare in sospeso è sbagliato.

Il monitor here (l'oggetto condiviso essendo bloccato su, che risulta essere t) è utilizzato per la comunicazione tra i vari fili, un thread chiama notifyAll sul monitor e gli altri thread in attesa sul monitor riceve la notifica. Puoi pensare al monitor come a un punto di comunicazione condiviso.

Nel primo esempio, il thread t inizia e termina immediatamente (perché non ha nulla da fare). Il thread termina e invia la sua notifica prima che il thread principale inizi ad attendere, quindi viene visualizzato un ritardo fino a quando scade l'attesa.

Nel secondo esempio, il thread t ha qualcosa da stampare, c'è una condizione di competizione tra esso e il thread principale. È un free-for-all, ciò che accade in primo luogo dipende dagli incidenti del tempismo. Quello che vedi è che il thread t ora deve stampare una riga sulla console, quindi riesce a rimanere occupato abbastanza a lungo da essere ancora attivo nel momento in cui il thread principale inizia ad attendere, consentendo al thread principale di ricevere la notifica quando t termina, il thread principale ne interrompe l'attesa.

Answer 2

Si è incappato esattamente nel motivo per cui non si dovrebbe MAI chiamare wait o notify(All) su Thread (vedere JavaDocs per Thread). Internamente, Thread utilizza wait e notifyAll per implementare Thread.join(), quindi cosa succede nel secondo caso il thread entra in attesa, ma poi l'altro thread muore e chiama notifyAll(), che riattiva il thread principale.

Utilizzare Thread.sleep se si desidera attendere un tempo trascorso, utilizzare Thread.join se si desidera effettivamente attendere la chiusura del thread. Inoltre, leggi javadocs in Object per l'uso corretto di wait, notify e notifyAll.

javaDoc:

public final void join(long millis) 
       throws InterruptedException 

Waits al massimo Millis millisecondi per questo thread morire. Un timeout di 0 significa aspettare per sempre. Questa implementazione utilizza un ciclo di chiamate this.wait condizionate su this.isive. Quando un thread termina il metodo , viene invocato il metodo this.notifyAll. Si consiglia alle applicazioni di non utilizzare le istanze wait, notify o notifyAll on Thread.