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

Question

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

El Documentation sur Thread.State :

Bloqué
Un thread qui est bloqué en attendant un verrou de moniteur est dans cet état.

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.

Answer 1

La différence est relativement simple.

Dans le BLOCKED un fil est sur le point d'entrer dans un synchronized mais un autre thread est en cours d'exécution dans un bloc synchronized sur le même objet. Le premier thread doit alors attendre que le deuxième thread sorte de son bloc.

Dans le WAITING 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 appelle Object.notify() ou meurt.

Answer 2

Un thread passe en état d'attente dès qu'il appelle wait() sur un objet. C'est ce qu'on appelle Attente État. Une fois qu'un thread a atteint l'état d'attente, il devra attendre qu'un autre thread appelle notify() o notifyAll() sur l'objet.

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

Une fois que les autres threads sont partis et que ce thread a de la chance, il passe à l'état Runnable, après quoi il peut reprendre le travail en fonction du mécanisme de threads de la JVM et passe à l'état Run.

Answer 3

La différence importante entre l'état bloqué et l'état d'attente est l'impact sur l'ordonnanceur. Un thread dans un état bloqué se bat pour un verrou ; ce thread compte toujours comme quelque chose que le planificateur doit gérer, et il est possible qu'il soit pris en compte dans les décisions du planificateur concernant le temps à accorder aux threads en cours d'exécution (afin de donner une chance aux threads qui bloquent le verrou).

Une fois qu'un thread est dans l'état d'attente, la pression qu'il exerce sur le système est minimisée et le planificateur n'a pas à s'en préoccuper. Il reste en sommeil jusqu'à ce qu'il reçoive une notification. À l'exception du fait qu'il maintient un thread du système d'exploitation occupé, il est entièrement hors jeu.

C'est la raison pour laquelle l'utilisation de notifyAll est loin d'être idéale, car elle réveille un tas de threads qui étaient auparavant joyeusement dormants et qui n'imposaient aucune charge au système. La plupart d'entre eux bloqueront jusqu'à ce qu'ils puissent acquérir le verrou, constateront que la condition qu'ils attendent n'est pas vraie et recommenceront à 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 seul verrou, de sorte que vous pouvez vous assurer que le thread notifié est celui qui attend une condition particulière, évitant ainsi le bug de la notification perdue dans le cas où un thread est notifié pour quelque chose sur lequel il ne peut pas agir).

Answer 4

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

• WAIT - J'attends qu'on me donne du travail, donc je suis inactif pour le moment.

• BLOCKED - Je suis occupé à essayer de travailler, mais un autre fil de discussion se trouve sur mon chemin, donc je suis inactif pour le moment.

• RUNNABLE ...(Native Method) - J'ai demandé l'exécution d'un code natif (qui n'est pas encore terminé), donc pour la JVM, vous êtes RUNNABLE et elle ne peut pas donner d'autres informations. Un exemple courant serait une méthode native d'écoute de socket codée en C qui attend en fait l'arrivée d'un trafic, donc je suis inactif en ce moment. Dans cette situation, on peut considérer qu'il s'agit d'un type spécial d'ATTENTE car nous ne sommes pas réellement EN COURS D'EXECUTION (pas de combustion du CPU), mais il faudrait utiliser un thread dump OS plutôt qu'un thread dump Java pour le voir.

Answer 5

Blocked- Votre thread est dans l'état runnable du cycle de vie des threads et tente d'obtenir le verrouillage de l'objet. Wait- Votre thread est dans l'état d'attente du cycle de vie du thread et attend le signal de notification pour arriver dans l'état exécutable du thread.