Java - wait et notifyAll

Question

Que se passe-t-il lorsque vous appelez la méthode notifyAll sur un objet qui n'attend pas? Devrait-il y avoir une exception ou est-ce une situation normale?

Answer 1

C'est tout à fait normal. Vous pouvez seulement notifier tout ce qui attend sur un seul moniteur. Tout le monde n'est pas intéressé. L'objet sur lequel vous appelez notifyAll est uniquement le moniteur sur lequel les autres attendent. Si personne n'attend, personne ne doit être averti

Answer 2

Comme vous pouvez le voir ici, l'appel de notifyAll() sur un objet non en attente n'a aucun effet.

Answer 3

objets en attente seulement averti. Object.wait() bloque jusqu'à un délai d'attente ou de notification - la question reste donc de savoir comment ou pourquoi pensez-vous que les objets non-attendus seraient jamais notifiés? cela n'a aucun sens.

Answer 4

L'objet est "en attente", ne pas attendre lui-même. Le fil est celui qui attend. Si personne n'attend, personne ne se réveillera et rien de spécial ne se produira.

Answer 5

Situation parfaitement normale. Imaginons que vous ayez une file d'attente avec un thread producteur qui y ajoute des éléments et un thread consommateur qui en supprime des éléments.

Maintenant que le consommateur a pu vider la file d'attente et être encore occupé par le traitement, personne n'attend que la file devienne non vide. Maintenant, le producteur ajoute un nouvel élément à la file d'attente. Il doit appeler notifyAll() pour réveiller le consommateur s'il attendait. Ajouter une logique supplémentaire pour vérifier si quelqu'un est en attente et n'appeler que notifyAll() dans ce cas ajouterait une complexité considérable (et très sujette à défaillance) au scénario - il est beaucoup plus facile d'appeler notifyAll() à chaque fois.

Answer 6

Je ne fais peut-être que fractionner les cheveux ;-) Il peut ne pas être strictement correct de penser à des threads qui passent de l'état 'waiting' à l'état 'running' sur notifyAll; au moins non sans la mise en garde que la première chose qu'un thread notifié fait est regrab le verrouillage du moniteur. Et puisque seul un des threads notifiés peut l'attraper, les autres seront bloqué. BLOQUÉ (Thread.State.Blocked) correspond à l'état du thread. Mais le blocage est pas la même chose que l'attente car le thread bloqué n'a pas besoin d'un autre signal notify() pour reprendre. [Eh bien, je connais des réveils intempestifs mais peut-être que le contraire pourrait également être vrai pour certaines implémentations JVM - un avis manqué?]

public class HellBoy { 
    public static class MyThread extends Thread { 
     static final public Object sharedLock = new Object(); 

     public void run() { 
      synchronized (sharedLock) { 
       System.out.println("Gonna wait..."); 
       try { 
        sharedLock.wait(); 
       } catch (InterruptedException e) { 
        e.printStackTrace(); 
       } 
       System.out.println("Woken up but sleeping with the lock"); 
       try { 
        Thread.sleep(2500); 
       } catch (InterruptedException e) { 
        e.printStackTrace(); 
       } 
       System.out.println("exiting and unlocking"); 
      } 
     } 
    } 

    public static void main(String[] args) throws Exception { 
     new MyThread().start(); 
     new MyThread().start(); 
     new MyThread().start(); 
     new MyThread().start(); 
     Thread.sleep(200); 
     synchronized (MyThread.sharedLock) { 
      MyThread.sharedLock.notifyAll(); 
     } 
    } 
}