Différence entre les états de thread WAIT et BLOCKED

Quelle est la différence entre l'état de thread WAIT et l'état de thread BLOCKED?

La documentation Thread.State :

Bloqué
Un thread bloqué en attente d'un verrouillage du moniteur est dans cet état.

En attente
Un thread qui attend indéfiniment qu'un autre thread effectue une action particulière est dans cet état

ne m'explique pas la différence.

Un thread passe à l'état d'attente une fois qu'il appelle wait()un objet. C'est ce qu'on appelle l' état d' attente . Une fois qu'un thread atteint l'état d'attente, il devra attendre qu'un autre thread appelle notify()ounotifyAll() sur l'objet.

Une fois que ce thread est notifié, il ne sera pas exécutable. Il se peut que d'autres threads soient également notifiés (en utilisant notifyAll()) ou que le premier thread n'ait pas terminé son travail, il est donc toujours bloqué jusqu'à ce qu'il ait sa chance. C'est ce qu'on appelle l' état bloqué . Un état bloqué se produit chaque fois qu'un thread essaie d'acquérir un verrou sur un objet et qu'un autre thread détient déjà le verrou.

Une fois que d'autres threads sont partis et que c'est cette chance de thread, il passe à l'état Runnable après qu'il est éligible au travail de ramassage basé sur le mécanisme de thread JVM et passe à l'état d'exécution.

La différence est relativement simple.

Dans l' BLOCKEDétat, un thread est sur le point d'entrer dans un synchronizedbloc, mais il y a un autre thread en cours d'exécution à l'intérieur d'un synchronizedbloc sur le même objet. Le premier thread doit ensuite attendre que le second thread quitte son bloc.

Dans l' WAITINGétat, un thread attend un signal d'un autre thread. Cela se produit généralement en appelant Object.wait()ou Thread.join(). Le thread restera alors dans cet état jusqu'à ce qu'un autre thread appelleObject.notify() ou meure.

La différence importante entre les états bloqué et d'attente est l'impact sur le planificateur. Un thread dans un état bloqué est en compétition pour un verrou; ce thread compte toujours comme quelque chose que le planificateur a besoin de traiter, pouvant être pris en compte dans les décisions du planificateur sur le temps imparti aux threads en cours d'exécution (afin qu'il puisse donner une chance aux threads bloquant sur le verrou).

Une fois qu'un thread est en état d'attente, le stress qu'il met sur le système est minimisé et le planificateur n'a pas à s'en soucier. Il passe en veille jusqu'à ce qu'il reçoive une notification. À l'exception du fait qu'il garde un thread du système d'exploitation occupé, il est entièrement hors jeu.

C'est pourquoi l'utilisation de notifyAll est loin d'être idéale, cela provoque le réveil d'un tas de threads qui étaient auparavant heureusement dormants sans aucune charge sur le système, où la plupart d'entre eux se bloqueront jusqu'à ce qu'ils puissent acquérir le verrou, trouver la condition dans laquelle ils sont attendre n'est pas vrai, et recommencez à attendre. Il serait préférable de ne notifier que les threads qui ont une chance de progresser.

(L'utilisation de ReentrantLock au lieu de verrous intrinsèques vous permet d'avoir plusieurs conditions pour un verrou, afin que vous puissiez vous assurer que le thread notifié est celui qui attend une condition particulière, évitant ainsi le bogue de notification de perte dans le cas où un thread est notifié pour quelque chose sur lequel il ne peut pas agir.)

Perspective simplifiée pour l'interprétation des thread dumps:

• ATTENDRE - J'attends qu'on me donne du travail, donc je suis inactif en ce moment.
  
• BLOQUÉ - Je suis occupé à essayer de faire le travail, mais un autre thread se trouve sur mon chemin, donc je suis inactif en ce moment.
  
• RUNNABLE ... (Native Method) - J'ai appelé à RUN un certain code natif (qui n'est pas encore terminé) donc en ce qui concerne la JVM, vous êtes RUNNABLE et il ne peut pas donner plus d'informations. Un exemple courant serait une méthode d'écoute de socket native codée en C qui attend en fait l'arrivée du trafic, donc je suis inactif pour le moment. Dans cette situation, cela peut être considéré comme un type particulier de WAIT car nous ne sommes pas en cours d'exécution (pas de brûlure du processeur) du tout, mais vous devrez utiliser un vidage de thread du système d'exploitation plutôt qu'un vidage de thread Java pour le voir.

Bloqué - Votre thread est dans l'état exécutable du cycle de vie du thread et tente d'obtenir le verrouillage d'objet. Wait - Votre thread est en attente du cycle de vie du thread et attend que le signal de notification entre dans l'état exécutable du thread.

voir cet exemple:

démonstration des états des threads.

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