Differenza tra gli stati del thread WAIT e BLOCKED

Qual è la differenza tra lo stato del thread WAIT e lo stato del thread BLOCKED?

La documentazione di Thread.State :

Bloccato
Un thread bloccato in attesa di un blocco del monitor si trova in questo stato.

In attesa
Un thread che attende indefinitamente che un altro thread esegua una particolare azione si trova in questo stato

non mi spiega la differenza.

Un thread passa allo stato di attesa una volta chiamato wait() un oggetto. Questo si chiama Waiting State. Una volta che un thread raggiunge lo stato di attesa, dovrà attendere fino a quando un altro thread non chiama notify()o notifyAll()sull'oggetto.

Una volta che questo thread viene notificato, non sarà più eseguibile. È possibile che anche altri thread ricevano una notifica (utilizzandonotifyAll() ) o il primo thread non abbia terminato il suo lavoro, quindi è ancora bloccato finché non ne ha la possibilità. Questo è chiamato stato bloccato . Uno stato Bloccato si verificherà ogni volta che un thread tenta di acquisire il blocco sull'oggetto e qualche altro thread sta già mantenendo il blocco.

Una volta che gli altri thread sono usciti e questa è la possibilità del thread, passa allo stato Runnable, dopodiché è idoneo a riprendere il lavoro in base al meccanismo di threading JVM e passa allo stato di esecuzione.

La differenza è relativamente semplice.

Nello BLOCKEDstato, un thread sta per entrare in un synchronizedblocco, ma c'è un altro thread attualmente in esecuzione all'interno di un synchronizedblocco sullo stesso oggetto. Il primo thread deve quindi attendere che il secondo thread esca dal blocco.

Nello WAITINGstato, un thread attende un segnale da un altro thread. Ciò accade in genere chiamando Object.wait(), o Thread.join(). Il thread rimarrà quindi in questo stato fino a quando un altro thread non chiama Object.notify()o muore.

L'importante differenza tra gli stati di blocco e di attesa è l'impatto sullo scheduler. Un thread in uno stato bloccato sta contendendo un blocco; quel thread conta ancora come qualcosa che lo scheduler deve servire, possibilmente preso in considerazione nelle decisioni dello scheduler su quanto tempo dare ai thread in esecuzione (in modo che possa dare una possibilità ai thread che si bloccano sul blocco).

Una volta che un thread è in stato di attesa, lo stress che mette sul sistema viene ridotto al minimo e lo scheduler non deve preoccuparsene. Rimane inattivo fino a quando non riceve una notifica. A parte il fatto che tiene occupato un thread del sistema operativo, è completamente fuori gioco.

Questo è il motivo per cui l'utilizzo di notifyAll è tutt'altro che ideale, causa il risveglio di un gruppo di thread che prima erano felicemente dormienti senza caricare il sistema, dove la maggior parte di loro si bloccherà fino a quando non potranno acquisire il blocco, trovare la condizione in cui sono aspettare non è vero, e tornare ad aspettare. Sarebbe preferibile notificare solo quei thread che hanno la possibilità di fare progressi.

(L'utilizzo di ReentrantLock al posto dei blocchi intrinseci consente di avere più condizioni per un blocco, in modo da poter assicurarsi che il thread notificato sia uno che è in attesa di una condizione particolare, evitando il bug di notifica persa nel caso in cui un thread venga notificato per qualcosa su cui non può agire.)

Prospettiva semplificata per interpretare i dump dei thread:

• ASPETTA - Sto aspettando che mi venga dato del lavoro, quindi sono inattivo in questo momento.
  
• BLOCCATO - Sono impegnato a portare a termine il lavoro, ma un altro thread mi ostacola, quindi sono inattivo in questo momento.
  
• ESEGUIBILE ... (Metodo nativo) - Ho chiamato per ESEGUIRE del codice nativo (che non è ancora terminato) quindi per quanto riguarda la JVM, sei RUNNABLE e non può fornire ulteriori informazioni. Un esempio comune sarebbe un metodo listener socket nativo codificato in C che è in realtà in attesa dell'arrivo di traffico, quindi sono inattivo in questo momento. In quella situazione, questo può essere visto come un tipo speciale di WAIT in quanto non stiamo effettivamente RUNNING (nessuna bruciatura della CPU) ma dovresti usare un dump del thread del sistema operativo piuttosto che un dump del thread Java per vederlo.

Bloccato: il thread è in uno stato eseguibile del ciclo di vita del thread e sta tentando di ottenere il blocco dell'oggetto. Attesa: il thread è in stato di attesa del ciclo di vita del thread e in attesa del segnale di notifica per entrare nello stato eseguibile del thread.

guarda questo esempio:

dimostrazione degli stati del thread.

/*NEW- thread object created, but not started.
RUNNABLE- thread is executing.
BLOCKED- waiting for monitor after calling wait() method.
WAITING- when wait() if called & waiting for notify() to be called.
  Also when join() is called.
TIMED_WAITING- when below methods are called:
 Thread.sleep
 Object.wait with timeout
 Thread.join with timeout
TERMINATED- thread returned from run() method.*/
public class ThreadBlockingState{

public static void main(String[] args) throws InterruptedException {
    Object obj= new Object();
    Object obj2 = new Object();
    Thread3 t3 = new Thread3(obj,obj2);
    Thread.sleep(1000);
    System.out.println("nm:"+t3.getName()+",state:"+t3.getState().toString()+
            ",when Wait() is called & waiting for notify() to be called.");
    Thread4 t4 = new Thread4(obj,obj2);
    Thread.sleep(3000);
    System.out.println("nm:"+t3.getName()+",state:"+t3.getState().toString()+",After calling Wait() & waiting for monitor of obj2.");
    System.out.println("nm:"+t4.getName()+",state:"+t4.getState().toString()+",when sleep() is called.");
}

}
class Thread3 extends Thread{
Object obj,obj2;
int cnt;
Thread3(Object obj,Object obj2){
    this.obj = obj;
    this.obj2 = obj2;
    this.start();
}

@Override
public void run() {
    super.run();
    synchronized (obj) {
        try {
            System.out.println("nm:"+this.getName()+",state:"+this.getState().toString()+",Before Wait().");
            obj.wait();             
            System.out.println("nm:"+this.getName()+",state:"+this.getState().toString()+",After Wait().");
            synchronized (obj2) {
                cnt++;
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
}
class Thread4 extends Thread{
Object obj,obj2;
Thread4(Object obj,Object obj2){
    this.obj = obj;
    this.obj2 = obj2;
    this.start();
}

@Override
public void run() {
    super.run();
    synchronized (obj) {
        System.out.println("nm:"+this.getName()+",state:"+this.getState().toString()+",Before notify().");
        obj.notify();
        System.out.println("nm:"+this.getName()+",state:"+this.getState().toString()+",After notify().");
    }
    synchronized (obj2) {
        try {
            Thread.sleep(15000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
}