Unterschied zwischen den Thread-Zuständen WAIT und BLOCKED

Was ist der Unterschied zwischen dem Thread-Status WAIT und dem Thread-Status BLOCKED?

Die Thread.State-Dokumentation :

Blockiert
Ein Thread, der blockiert ist und auf eine Monitorsperre wartet, befindet sich in diesem Status.

Warten
Ein Thread, der auf unbestimmte Zeit darauf wartet, dass ein anderer Thread eine bestimmte Aktion ausführt, befindet sich in diesem Status

erklärt mir den Unterschied nicht.

Ein Thread wartet, sobald er wait()ein Objekt aufruft . Dies wird als Wartezustand bezeichnet . Sobald ein Thread den Wartezustand erreicht, muss er warten, bis ein anderer Thread notify()oder notifyAll()das Objekt aufgerufen wird.

Sobald dieser Thread benachrichtigt wurde, kann er nicht mehr ausgeführt werden. Es kann sein, dass andere Threads ebenfalls benachrichtigt werden (using notifyAll()) oder der erste Thread seine Arbeit noch nicht beendet hat, sodass er immer noch blockiert ist, bis er seine Chance bekommt. Dies wird als blockierter Zustand bezeichnet. Ein blockierter Status tritt immer dann auf, wenn ein Thread versucht, eine Sperre für ein Objekt zu erlangen, und ein anderer Thread die Sperre bereits hält.

Sobald andere Threads abgereist sind und diese Thread-Chance besteht, wechselt sie in den Status "Ausführbar". Danach ist sie berechtigt, Arbeiten basierend auf dem JVM-Threading-Mechanismus aufzunehmen, und wechselt in den Status "Ausführen".

Der Unterschied ist relativ einfach.

In diesem BLOCKEDZustand ist ein Thread im Begriff, einen synchronizedBlock einzugeben , aber es wird derzeit ein anderer Thread in einem synchronizedBlock für dasselbe Objekt ausgeführt. Der erste Thread muss dann warten, bis der zweite Thread seinen Block verlassen hat.

In diesem WAITINGZustand wartet ein Thread auf ein Signal von einem anderen Thread. Dies geschieht normalerweise durch Aufrufen von Object.wait()oder Thread.join(). Der Thread bleibt dann in diesem Zustand, bis ein anderer Thread aufruft Object.notify()oder stirbt.

Der wichtige Unterschied zwischen dem blockierten und dem Wartezustand ist die Auswirkung auf den Scheduler. Ein Thread in einem blockierten Zustand kämpft um eine Sperre. Dieser Thread zählt immer noch als etwas, das der Scheduler warten muss, und wird möglicherweise in die Entscheidungen des Schedulers einbezogen, wie viel Zeit für laufende Threads zur Verfügung steht (damit die Threads, die die Sperre blockieren, eine Chance erhalten).

Sobald sich ein Thread im Wartezustand befindet, wird die Belastung des Systems minimiert, und der Scheduler muss sich keine Sorgen mehr machen. Es wird ruhend, bis es eine Benachrichtigung erhält. Abgesehen von der Tatsache, dass ein Betriebssystem-Thread besetzt bleibt, ist es völlig aus dem Spiel.

Aus diesem Grund ist die Verwendung von notifyAll weniger als ideal. Es führt dazu, dass eine Reihe von Threads, die zuvor glücklich ruhten und das System nicht belasteten, aufgeweckt wurden. Die meisten von ihnen blockieren, bis sie die Sperre erlangen und den Zustand finden, in dem sie sich befinden Warten ist nicht wahr, und kehren Sie zum Warten zurück. Es wäre vorzuziehen, nur diejenigen Threads zu benachrichtigen, die eine Chance auf Fortschritte haben.

(Wenn Sie ReentrantLock anstelle von intrinsischen Sperren verwenden, können Sie mehrere Bedingungen für eine Sperre festlegen, sodass Sie sicherstellen können, dass der benachrichtigte Thread auf eine bestimmte Bedingung wartet, und den Fehler bei der Benachrichtigung über verlorene Benachrichtigungen vermeiden, wenn ein Thread benachrichtigt wird etwas, auf das es nicht einwirken kann.)

Vereinfachte Perspektive für die Interpretation von Thread-Dumps:

• WARTEN - Ich warte darauf, etwas Arbeit zu bekommen, also bin ich gerade untätig.
  
• BLOCKED - Ich bin damit beschäftigt, die Arbeit zu erledigen, aber ein anderer Thread steht mir im Weg, also bin ich gerade untätig.
  
• RUNNABLE ... (native Methode) - Ich habe aufgerufen, einen nativen Code (der noch nicht fertig ist) auszuführen, was die JVM betrifft. Sie sind RUNNABLE und können keine weiteren Informationen geben. Ein häufiges Beispiel wäre eine in C codierte native Socket-Listener-Methode, die tatsächlich auf das Eintreffen von Datenverkehr wartet. Ich bin also gerade inaktiv. In dieser Situation kann dies als eine besondere Art von WARTEN angesehen werden, da wir eigentlich gar nicht LAUFEN (kein CPU-Brennvorgang), aber Sie müssten einen Betriebssystem-Thread-Dump anstelle eines Java-Thread-Dumps verwenden, um dies zu sehen.

Blockiert - Ihr Thread befindet sich im ausführbaren Zustand des Thread-Lebenszyklus und versucht, eine Objektsperre zu erhalten. Warten - Ihr Thread befindet sich im Wartezustand des Thread-Lebenszyklus und wartet darauf, dass das Benachrichtigungssignal in den ausführbaren Zustand des Threads gelangt.

siehe dieses Beispiel:

Demonstration von Thread-Zuständen.

/*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();
        }
    }
}
}