Différence entre wait () et sleep ()

Quelle est la différence entre a wait()et sleep()dans Threads?

Est-ce que je comprends qu'un wait()thread -ing est toujours en mode de fonctionnement et utilise des cycles CPU mais qu'un sleep()-ing ne consomme aucun cycle CPU correct?

Pourquoi avons-nous les deux wait() et sleep(): comment leur mise en œuvre varie-t-elle à un niveau inférieur?

Un waitpeut être "réveillé" par un autre thread appelant notifyle moniteur qui est attendu alors qu'un sleepne peut pas. De plus, un wait(et notify) doit se produire dans un bloc synchronizedsur l'objet moniteur alors que sleepne:

Object mon = ...;
synchronized (mon) {
    mon.wait();
} 

À ce stade, le thread en cours d'exécution attend et libère le moniteur . Un autre fil peut faire

synchronized (mon) { mon.notify(); }

(sur le même monobjet) et le premier thread (en supposant que c'est le seul thread en attente sur le moniteur) se réveillera.

Vous pouvez également appeler notifyAllsi plusieurs threads attendent sur le moniteur - cela les réveillera tous . Cependant, un seul des threads pourra saisir le moniteur (rappelez-vous que le waitest dans un synchronizedbloc) et continuer - les autres seront alors bloqués jusqu'à ce qu'ils puissent acquérir le verrouillage du moniteur.

Un autre point est que vous appelez waitsur Objectlui - même (vous attendez sur le moniteur d'un objet) alors que vous appelez sleeple Thread.

Pourtant , un autre point est que vous pouvez obtenir des redémarrages parasites de wait(le fil qui est en attente reprend sans raison apparente). Vous devriez toujours waitpendant la rotation à certaines conditions comme suit:

synchronized {
    while (!condition) { mon.wait(); }
}

Une différence clé non encore mentionnée est que pendant le sommeil, un thread ne libère pas les verrous qu'il détient, tandis que l'attente libère le verrou sur l'objet wait()appelé.

synchronized(LOCK) {
    Thread.sleep(1000); // LOCK is held
}


synchronized(LOCK) {
    LOCK.wait(); // LOCK is not held
}

J'ai trouvé ce post utile. Il met la différence entre Thread.sleep(), Thread.yield()et Object.wait()en termes humains. Citer:

Tout cela finit par arriver au planificateur du système d'exploitation, qui distribue des tranches de temps aux processus et aux threads.

sleep(n)dit "J'ai fini avec ma tranche de temps, et s'il vous plaît ne m'en donnez pas une autre pendant au moins n millisecondes." Le système d'exploitation n'essaie même pas de planifier le thread en veille jusqu'à ce que le temps demandé soit écoulé.

yield()dit "J'ai fini avec ma tranche de temps, mais j'ai encore du travail à faire." Le système d'exploitation est libre de donner immédiatement au thread une autre tranche de temps, ou de donner un autre thread ou de traiter le processeur que le thread cédant vient d'abandonner.

wait()dit «J'ai fini avec ma tranche de temps. Ne me donnez pas une autre tranche de temps jusqu'à ce que quelqu'un appelle (). » Comme avec sleep(), le système d'exploitation n'essaiera même pas de planifier votre tâche à moins que quelqu'un n'appelle notify()(ou l'un des quelques autres scénarios de réveil se produit).

Les threads perdent également le reste de leur tranche de temps lorsqu'ils effectuent le blocage des E / S et dans quelques autres circonstances. Si un thread fonctionne sur l'intégralité de la tranche de temps, le système d'exploitation prend à peu près le contrôle comme s'il yield()avait été appelé, afin que d'autres processus puissent s'exécuter.

Vous en avez rarement besoin yield(), mais si vous avez une application lourde en calcul avec des limites de tâches logiques, l'insertion d'un yield() pourrait améliorer la réactivité du système (au détriment du temps - les changements de contexte, même uniquement vers le système d'exploitation et inversement, ne sont pas gratuits). Mesurez et testez par rapport aux objectifs qui vous tiennent à cœur, comme toujours.

Il y a beaucoup de réponses ici mais je n'ai trouvé la distinction sémantique mentionnée sur aucune.

Il ne s'agit pas du fil lui-même; les deux méthodes sont nécessaires car elles prennent en charge des cas d'utilisation très différents.

sleep()envoie le thread en veille comme il l'était auparavant, il ne fait que compresser le contexte et arrête de s'exécuter pendant une durée prédéfinie. Donc, pour le réveiller avant l'heure prévue, vous devez connaître la référence Thread. Ce n'est pas une situation courante dans un environnement multithread. Il est principalement utilisé pour la synchronisation de l'heure (par exemple, réveil en 3,5 secondes exactement) et / ou l'équité codée en dur (il suffit de dormir pendant un certain temps et de laisser les autres threads fonctionner).

wait(), au contraire, est un mécanisme de synchronisation de thread (ou de message) qui vous permet de notifier un Thread dont vous n'avez aucune référence stockée (ni attention). Vous pouvez le considérer comme un modèle de publication-abonnement ( wait== abonnement et notify()== publication). Fondamentalement, en utilisant notify (), vous envoyez un message (qui pourrait même ne pas être reçu du tout et normalement vous ne vous en souciez pas).

Pour résumer, vous utilisez normalement la sleep()synchronisation temporelle et la synchronisation wait()multi-thread.

Ils pouvaient être implémentés de la même manière dans le système d'exploitation sous-jacent, ou pas du tout (car les versions précédentes de Java n'avaient pas de véritable multithreading; probablement certaines petites machines virtuelles ne le font pas non plus). N'oubliez pas que Java s'exécute sur une VM, donc votre code sera transformé en quelque chose de différent en fonction de la VM / OS / HW sur laquelle il s'exécute.

Ici, j'ai énuméré quelques différences importantes entre les méthodes wait()et sleep().
PS: Cliquez également sur les liens pour voir le code de la bibliothèque (fonctionnement interne, il suffit de jouer un peu pour une meilleure compréhension).

attendre()

1. wait() libère le verrou.
2. wait()est la méthode de Objectclasse.
3. wait() est la méthode non statique - public final void wait() throws InterruptedException { //...}
4. wait()doivent être notifiés par notify()ou notifyAll()méthodes.

5. wait() La méthode doit être appelée à partir d'une boucle afin de traiter les fausses alarmes.

6. wait() La méthode doit être appelée à partir d'un contexte synchronisé (c'est-à-dire une méthode synchronisée ou un bloc), sinon elle lancera IllegalMonitorStateException

dormir()

1. sleep() ne libère pas le verrou.
2. sleep()est la méthode de java.lang.Threadclasse.
3. sleep() est la méthode statique - public static void sleep(long millis, int nanos) throws InterruptedException { //... }
4. après la durée spécifiée, sleep()est terminée.
5. sleep()mieux ne pas appeler depuis la boucle (c'est -à- dire voir le code ci-dessous ).
6. sleep()peut être appelé de n'importe où. il n'y a pas d'exigence spécifique.

Réf: Différence entre attente et sommeil

Extrait de code pour appeler la méthode wait et sleep

synchronized(monitor){
    while(condition == true){ 
        monitor.wait()  //releases monitor lock
    }

    Thread.sleep(100); //puts current thread on Sleep    
}

Il y a quelques notes clés de différence que je conclus après avoir travaillé sur l'attente et le sommeil, jetez d'abord un coup d'œil sur l'échantillon en utilisant wait () et sleep ():

Exemple 1 : en utilisant wait () et sleep ():

synchronized(HandObject) {
    while(isHandFree() == false) {
        /* Hand is still busy on happy coding or something else, please wait */
        HandObject.wait();
    }
}

/* Get lock ^^, It is my turn, take a cup beer now */
while (beerIsAvailable() == false) {
    /* Beer is still coming, not available, Hand still hold glass to get beer,
       don't release hand to perform other task */
    Thread.sleep(5000);
}

/* Enjoy my beer now ^^ */
drinkBeers();

/* I have drink enough, now hand can continue with other task: continue coding */
setHandFreeState(true);
synchronized(HandObject) {
    HandObject.notifyAll();
}

Laissez la clarté quelques notes clés:

1. Appelez :
   • wait (): Appel sur le thread actuel qui contient l'objet HandObject
   • sleep (): Appelez la tâche d'exécution du thread pour obtenir de la bière (la méthode de classe affecte donc le thread en cours d'exécution)
2. Synchronisé :
   • wait (): lorsque plusieurs threads synchronisés accèdent au même objet (HandObject) (Lorsque vous avez besoin d'une communication entre plusieurs threads (thread exécuter le codage, thread exécuter obtenir de la bière) accès sur le même objet HandObject)
   • sleep (): lorsque la condition d'attente pour continuer à s'exécuter (bière en attente disponible)
3. Maintenez le verrou :
   • wait (): relâchez le verrou pour que d'autres objets aient la chance de s'exécuter (HandObject est gratuit, vous pouvez faire un autre travail)
   • sleep (): garder le verrou pendant au moins t fois (ou jusqu'à l'interruption) (Mon travail n'est toujours pas terminé, je continue à maintenir le verrou et j'attends une condition pour continuer)
4. Condition de réveil :
   • wait (): jusqu'à ce que l'appel notifie (), notifyAll () de l'objet
   • sleep (): jusqu'à expiration au moins du temps ou interruption de l'appel
5. Et le dernier point est à utiliser quand, comme l' estani l' indique:

vous utilisez normalement sleep () pour la synchronisation horaire et wait () pour la synchronisation multi-thread.

Corrigez-moi si j'ai tort, s'il-vous plait.

Différence entre wait () et sleep ()

• La différence fondamentale est que wait()provient Objectet sleep()est une méthode statique Thread.

• La principale différence est que wait()le sleep()déverrouillage ne libère aucun verrou en attendant.

• wait()est utilisé pour la communication inter-thread tandis que sleep()est utilisé pour introduire une pause sur l'exécution, en général.

• wait()devrait être appelé depuis synchroniser à l'intérieur ou bien nous obtenons un IllegalMonitorStateException, tandis que sleep() peut être appelé n'importe où.

• Pour relancer un fil depuis wait(), vous devez appeler notify()ou notifyAll(). Quant sleep(),au thread, il démarre après un intervalle de temps spécifié.

Similitudes

• Les deux font passer le thread en cours dans l' état Non exécutable .
• Les deux sont des méthodes natives .

C'est une question très simple, car ces deux méthodes ont une utilisation totalement différente.

La principale différence est d'attendre pour libérer le verrou ou le moniteur pendant que le sommeil ne libère aucun verrou ou moniteur pendant l'attente. Wait est utilisé pour la communication entre les threads tandis que sleep est utilisé pour introduire une pause lors de l'exécution.

Ce n'était qu'une explication claire et basique, si vous voulez plus que cela, continuez à lire.

En cas de wait()thread de méthode en attente et il ne reviendra pas automatiquement jusqu'à ce que nous appelions la notify()méthode (ou notifyAll()si vous avez plus d'un thread en attente et que vous souhaitez réveiller tous ces threads). Et vous avez besoin synchronisé ou verrouillage de l' objet ou le verrouillage de classe pour accéder au wait()ou notify()ou notifyAll()méthodes. Et encore une chose, la wait()méthode est utilisée pour la communication entre les threads, car si un thread passe en attente, vous aurez besoin d'un autre thread pour le réveiller.

Mais dans ce cas, sleep()c'est une méthode qui est utilisée pour maintenir le processus pendant quelques secondes ou le temps que vous voulez. Parce que vous n'avez pas besoin de provoquer une notify()ou notifyAll()méthode pour obtenir ce retour de fil. Ou vous n'avez besoin d'aucun autre fil pour rappeler ce fil. Comme si vous voulez que quelque chose se produise après quelques secondes, comme dans un jeu après le tour de l'utilisateur, vous voulez que l'utilisateur attende que l'ordinateur joue, alors vous pouvez mentionner la sleep()méthode.

Et une autre différence importante qui est souvent demandée lors des entretiens: sleep()appartient à la Threadclasse et wait()appartient à la Objectclasse.

Ce sont toutes les différences entre sleep()et wait().

Et il existe une similitude entre les deux méthodes: elles sont toutes deux vérifiées, vous devez donc essayer catch ou throw pour accéder à ces méthodes.

J'espère que cela t'aidera.

source: http://www.jguru.com/faq/view.jsp?EID=47127

Thread.sleep()envoie le thread actuel à l'état "Non exécutable" pendant un certain temps. Le thread conserve les moniteurs qu'il a acquis - c'est-à-dire si le thread est actuellement dans un bloc ou une méthode synchronisée, aucun autre thread ne peut entrer dans ce bloc ou cette méthode. Si un autre thread appelle, t.interrupt()il réveillera le thread endormi.

Notez que sleep est une méthode statique, ce qui signifie qu'elle affecte toujours le thread actuel (celui qui exécute la méthode sleep). Une erreur courante consiste à appeler t.sleep()où t est un thread différent; même alors, c'est le thread actuel qui dormira, pas le thread t.

t.suspend()est obsolète. Son utilisation permet d'arrêter un thread autre que le thread actuel. Un thread suspendu conserve tous ses moniteurs et comme cet état n'est pas interruptible, il est sujet à un blocage.

object.wait()envoie le thread actuel dans l'état "Not Runnable" , comme sleep(), mais avec une torsion. L'attente est appelée sur un objet, pas sur un thread; nous appelons cet objet «l'objet verrouillé». Avant que lock.wait()soit appelé, le thread actuel doit se synchroniser sur l'objet de verrouillage; wait() libère ensuite ce verrou et ajoute le fil à la "liste d'attente" associée au verrou. Plus tard, un autre thread peut se synchroniser sur le même objet de verrouillage et appeler lock.notify(). Cela réveille le fil d'origine en attente. Fondamentalement, wait()/ notify()est similaire à sleep()/ interrupt(), seul le thread actif n'a pas besoin d'un pointeur direct vers le thread endormi, mais uniquement vers l'objet de verrouillage partagé.

Attendre et dormir sont deux choses différentes:

• Dans sleep()le thread cesse de fonctionner pendant la durée spécifiée.
• Dans wait()le thread cesse de fonctionner jusqu'à ce que l'objet attendu soit notifié, généralement par d'autres threads.

sleepest une méthode de Thread, waitest une méthode de Object, wait/notifyest donc une technique de synchronisation des données partagées en Java (en utilisant le moniteur ), mais sleepest une méthode simple de thread pour se mettre en pause.

sleep () est une méthode qui est utilisée pour maintenir le processus pendant quelques secondes ou le temps que vous vouliez mais en cas de thread de méthode wait () passe en état d'attente et il ne reviendra pas automatiquement jusqu'à ce que nous appelons le notify () ou notifyAll ().

La principale différence est que wait () libère le verrou ou le moniteur pendant que sleep () ne libère aucun verrou ou moniteur pendant l'attente. Wait est utilisé pour la communication entre les threads tandis que sleep est utilisé pour introduire une pause lors de l'exécution, en général.

Thread.sleep () envoie le thread actuel à l'état "Not Runnable" pendant un certain temps. Le thread conserve les moniteurs qu'il a acquis - c'est-à-dire que si le thread est actuellement dans un bloc ou une méthode synchronisée, aucun autre thread ne peut entrer dans ce bloc ou cette méthode. Si un autre thread appelle t.interrupt (), il réveillera le thread en veille. Notez que sleep est une méthode statique, ce qui signifie qu'elle affecte toujours le thread actuel (celui qui exécute la méthode sleep). Une erreur courante consiste à appeler t.sleep () où t est un thread différent; même alors, c'est le thread actuel qui dormira, pas le thread t.

object.wait () envoie le thread actuel dans l'état "Not Runnable", comme sleep (), mais avec une torsion. L'attente est appelée sur un objet, pas sur un thread; nous appelons cet objet «l'objet verrouillé». Avant d'appeler lock.wait (), le thread actuel doit se synchroniser sur l'objet lock; wait () libère alors ce verrou et ajoute le fil à la «liste d'attente» associée au verrou. Plus tard, un autre thread peut se synchroniser sur le même objet de verrouillage et appeler lock.notify (). Cela réveille le fil d'origine en attente. Fondamentalement, wait () / notify () est comme sleep () / interrupt (), seul le thread actif n'a pas besoin d'un pointeur direct vers le thread endormi, mais uniquement vers l'objet de verrouillage partagé.

synchronized(LOCK) {   
   Thread.sleep(1000); // LOCK is held
}

synchronized(LOCK) {   
   LOCK.wait(); // LOCK is not held
}

Classons tous les points ci-dessus:

Call on:

• wait (): appeler un objet; le thread actuel doit se synchroniser sur l'objet de verrouillage.
• sleep (): Appel sur un fil; toujours en cours d'exécution du thread.

Synchronized:

• wait (): lorsque plusieurs threads synchronisés accèdent au même objet un par un.
• sleep (): lors de la synchronisation de plusieurs threads, attendez la mise en veille du thread en veille.

Hold lock:

• wait (): relâchez le verrou pour que d'autres objets aient la chance de s'exécuter.
• sleep (): garder le verrouillage pendant au moins t fois si le délai d'attente est spécifié ou si quelqu'un l'interrompt.

Wake-up condition:

• wait (): jusqu'à ce que l'appel notifie (), notifyAll () de l'objet
• sleep (): jusqu'à expiration au moins du temps ou interruption d'appel ().

Usage:

• sleep (): pour la synchronisation de l'heure et;
• wait (): pour la synchronisation multi-thread.

Réf: diff sleepetwait

En termes simples, wait is wait Jusqu'à ce qu'un autre thread vous invoque alors que sleep est "don't execute next statement" pendant une période de temps spécifiée.

De plus, sleep est une méthode statique dans la classe Thread et il fonctionne sur le thread, tandis que wait () est dans la classe Object et appelé sur un objet.

Un autre point, lorsque vous appelez wait sur un objet, le thread impliqué synchronise l'objet, puis attend. :)

waitet les sleepméthodes sont très différentes:

• sleep n'a aucun moyen de "se réveiller",
• alors qu'il waita un moyen de "se réveiller" pendant la période d'attente, par un autre thread appelant notifyou notifyAll.

À bien y penser, les noms prêtent à confusion à cet égard; sleepest cependant un nom standard et waitressemble à WaitForSingleObjectou WaitForMultipleObjectsdans l'API Win.

De cet article: http://javaconceptoftheday.com/difference-between-wait-and-sleep-methods-in-java/

Méthode wait ().

1) Le thread qui appelle la méthode wait () libère le verrou qu'il détient.

2) Le thread retrouve le verrou après que d'autres threads ont appelé les méthodes notify () ou notifyAll () sur le même verrou.

3) la méthode wait () doit être appelée dans le bloc synchronisé.

4) La méthode wait () est toujours appelée sur les objets.

5) Les threads en attente peuvent être réveillés par d'autres threads en appelant les méthodes notify () ou notifyAll ().

6) Pour appeler la méthode wait (), le thread doit avoir un verrou d'objet.

sleep (), méthode

1) Le thread qui appelle la méthode sleep () ne libère pas le verrou qu'il détient.

2) la méthode sleep () peut être appelée à l'intérieur ou à l'extérieur du bloc synchronisé.

3) La méthode sleep () est toujours appelée sur les threads.

4) Les fils dormants ne peuvent pas être réveillés par d'autres fils. Si c'est le cas, le thread lèvera InterruptedException.

5) Pour appeler la méthode sleep (), le thread n'a pas besoin d'avoir le verrouillage d'objet.

Ici, wait () sera dans l'état d'attente jusqu'à ce qu'il le notifie par un autre thread, mais où sleep () aura un certain temps..après cela, il passera automatiquement à l'état Ready ...

1. wait()est une méthode de Objectclasse.
   sleep()est une méthode de Threadclasse.

2. sleep()permet au thread de passer à l' sleepétat pendant x millisecondes.
   Lorsqu'un fil se met en veille it doesn’t release the lock.

3. wait()permet au fil de libérer le verrou et goes to suspended state.
   Ce thread sera actif lorsqu'une méthode notify()or notifAll()sera appelée pour le même objet.

Une grande différence potentielle entre sommeil / interruption et attente / notification est que

• appeler interrupt()pendant sleep()lève toujours une exception (par exemple, InterruptedException ), tandis que
• appeler notify()pendant wait()ne fonctionne pas.

Générer une exception lorsqu'elle n'est pas nécessaire est inefficace. Si vous avez des threads qui communiquent entre eux à un taux élevé, cela générerait de nombreuses exceptions si vous appeliez constamment interruption, ce qui est un gaspillage total de CPU.

Vous avez raison - Sleep () fait que ce thread se "met en veille" et le CPU s'éteint et traite les autres threads (autrement connu sous le nom de changement de contexte) alors que je pense que Wait attend que le CPU traite le thread actuel.

Nous avons les deux parce que même si cela peut sembler judicieux de laisser d'autres personnes utiliser le processeur pendant que vous ne l'utilisez pas, en réalité, il y a un surcoût pour le changement de contexte - selon la durée du sommeil, il peut être plus cher dans les cycles du processeur pour changer de threads que pour simplement avoir votre thread ne rien faire pendant quelques ms.

Notez également que le sommeil force un changement de contexte.

De plus - en général, il n'est pas possible de contrôler le changement de contexte - pendant l'attente, le système d'exploitation peut (et va attendre plus longtemps) choisir de traiter d'autres threads.

Les méthodes sont utilisées pour différentes choses.

Thread.sleep(5000);   // Wait until the time has passed.

Object.wait();        // Wait until some other thread tells me to wake up.

Thread.sleep (n) peut être interrompu, mais Object.wait () doit être notifié. Il est possible de spécifier le temps maximum à attendre: Object.wait(5000)il serait donc possible d'utiliser waitpour, euh, sleepmais alors vous devez vous soucier des verrous.

Aucune des méthodes n'utilise le processeur pendant le sommeil / l'attente.

Les méthodes sont implémentées en utilisant du code natif, en utilisant des constructions similaires mais pas de la même manière.

Cherchez par vous-même: le code source des méthodes natives est-il disponible? Le fichier /src/share/vm/prims/jvm.cppest le point de départ ...

Attendre () et dormir () Différences?

Thread.sleep () Une fois son travail terminé, il ne reste plus qu'à libérer le verrou à tout le monde. jusqu'à ce que cela ne libère jamais le verrou à personne.

  Sleep() take the key, its never release the key to anyone, when its work completed then only its release then only take the key waiting stage threads.

Object.wait () Lorsqu'il passera à l'étape d'attente, il relâchera la clé et attendra quelques secondes en fonction du paramètre.

Par exemple:

vous prenez le café dans la main droite, vous pouvez prendre un autre personne de la même main, quand allez-vous déposer puis ne prendre qu'un autre objet du même type ici. aussi. c'est le sommeil () vous dormez, vous n'avez pas travaillé, vous ne faites que dormir .. même ici aussi.

attendre(). quand vous êtes abattu et prenez un autre moyen pendant que vous attendez, c'est attendre

vous jouez un film ou quoi que ce soit dans votre système de la même manière que le joueur, vous ne pouvez pas en jouer plus d'un à la fois, c'est ici, lorsque vous fermez et choisissez un autre film ou chanson de quelqu'un pendant que s'appelle attendre

waitlibère le verrou et sleepne le fait pas. Un fil dans l' état d' attente est admissible à se réveiller dès notifyou notifyAllest appelé. Mais dans le cas où sleeple fil garde le verrou et il ne sera éligible qu'une fois le temps de sommeil terminé.

sleep()fait en sorte que le thread en cours passe de l'état d'exécution à l'état de blocage pendant une durée spécifiée. Si le thread actuel a le verrou de n'importe quel objet, il continue à le maintenir, ce qui signifie que les autres threads ne peuvent exécuter aucune méthode synchronisée dans cet objet de classe.

wait() La méthode fait que le thread actuel entre dans l'état de bloc pendant une durée spécifiée ou jusqu'à notification, mais dans ce cas, le thread libère le verrou de l'objet (ce qui signifie que d'autres threads peuvent exécuter toutes les méthodes synchronisées de l'objet appelant.

À mon avis, la principale différence entre les deux mécanismes est que le mode veille / interruption est le moyen le plus élémentaire de gérer les threads, tandis que l' attente / notification est une abstraction visant à faciliter l'intercommunication des threads.Cela signifie que le sommeil / interruption peut tout faire, mais que cette tâche spécifique est plus difficile à faire.

Pourquoi attendre / notifier est-il plus approprié? Voici quelques considérations personnelles:

1. Il impose la centralisation. Il permet de coordonner la communication entre un groupe de threads avec un seul objet partagé. Cela simplifie beaucoup le travail.

2. Il applique la synchronisation. Parce que le programmeur encapsule l'appel pour attendre / notifier dans un bloc synchronisé.

3. Il est indépendant de l'origine et du numéro du fil. Avec cette approche, vous pouvez ajouter plus de fils arbitrairement sans modifier les autres fils ou garder une trace de ceux existants. Si vous avez utilisé sleep / interruption, vous devez d'abord conserver les références aux threads en veille, puis les interrompre une par une, à la main.

Un exemple de la vie réelle qui est bon d'expliquer c'est un restaurant classique et la méthode que le personnel utilise pour communiquer entre eux: Les serveurs laissent les demandes des clients dans un endroit central (une planche de liège, une table, etc.), sonner la cloche, et les ouvriers de la cuisine viennent prendre ces demandes. Une fois qu'un cours est prêt, le personnel de cuisine sonne à nouveau pour que les serveurs soient au courant et les amènent aux clients.

Un exemple de sommeil ne libère pas le verrou et

Ici, il y a deux classes:

1. Main : contient la méthode principale et deux threads.

2. Singleton : il s'agit de la classe singleton avec deux méthodes statiques getInstance () et getInstance (boolean isWait).

   public class Main {
   
   private static Singleton singletonA = null;
   private static Singleton singletonB = null;
   
   public static void main(String[] args) throws InterruptedException {
   
   Thread threadA = new Thread() {
       @Override
       public void run() {
   
           singletonA = Singleton.getInstance(true);
   
       }
   };
   
   Thread threadB = new Thread() {
       @Override
       public void run() {
           singletonB = Singleton.getInstance();
   
           while (singletonA == null) {
               System.out.println("SingletonA still null");
           }
   
           if (singletonA == singletonB) {
               System.out.println("Both singleton are same");
           } else {
               System.out.println("Both singleton are not same");
           }
   
       }
   };
   
   threadA.start();
   threadB.start();
   
    }
   }

et

public class Singleton {

    private static Singleton _instance;

    public static Singleton getInstance() {

    if (_instance == null) {
        synchronized (Singleton.class) {
            if (_instance == null)
                _instance = new Singleton();
        }
    }
    return _instance;

}

public static Singleton getInstance(boolean isWait) {

    if (_instance == null) {
        synchronized (Singleton.class) {
            if (_instance == null) {
                if (isWait) {
                    try {
                        // Singleton.class.wait(500);//Using wait
                        Thread.sleep(500);// Using Sleep
                        System.out.println("_instance :"
                                + String.valueOf(_instance));
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

                _instance = new Singleton();
            }
        }
    }
    return _instance;

 }
}

Maintenant, exécutez cet exemple, vous obtiendrez ci-dessous la sortie:

_instance :null
Both singleton are same

Ici, les instances Singleton créées par threadA et threadB sont identiques. Cela signifie que le threadB attend à l'extérieur jusqu'à ce que le threadA libère son verrou.

Maintenant, changez Singleton.java en commentant Thread.sleep (500); méthode et décommentation Singleton.class.wait (500); . Ici à cause de Singleton.class.wait (500); La méthode threadA libérera tous les verrous d'acquisition et passera à l'état «Non exécutable», threadB obtiendra la modification à entrer dans le bloc synchronisé.

Maintenant, exécutez à nouveau:

SingletonA still null
SingletonA still null
SingletonA still null
_instance :com.omt.sleepwait.Singleton@10c042ab
SingletonA still null
SingletonA still null
SingletonA still null
Both singleton are not same

Ici, les instances Singleton créées par threadA et threadB ne sont PAS les mêmes car threadB a obtenu une modification pour entrer dans le bloc synchronisé et après 500 millisecondes, threadA a démarré à partir de sa dernière position et a créé un autre objet Singleton.

Doit être appelée à partir du bloc synchronisé: la wait() méthode est toujours appelée à partir du bloc synchronisé, c'est-à-dire que la wait()méthode doit verrouiller le moniteur d'objet avant l'objet sur lequel elle est appelée. Mais la sleep()méthode peut être appelée depuis un bloc synchronisé externe, c'est-à-dire qu'elle sleep()n'a pas besoin de moniteur d'objet.

IllegalMonitorStateException: si la wait()méthode est appelée sans acquérir le verrou d'objet, elle IllegalMonitorStateExceptionest levée lors de l'exécution, maissleep() méthode ne lève jamais une telle exception.

Appartient à quelle classe: la wait() méthode appartient à la java.lang.Objectclasse mais la sleep()méthode appartient à la java.lang.Threadclasse.

Appelé sur un objet ou un thread: la wait() méthode est appelée sur les objets mais la sleep()méthode est appelée sur les threads et non sur les objets.

État du thread: lorsque la wait()méthode est appelée sur l'objet, le thread qui contenait le moniteur de l'objet passe de l'état d'exécution à l'état d'attente et ne peut revenir à l'état d'exécution que lorsque la méthode notify()ou notifyAll()est appelée sur cet objet. Et plus tard, le planificateur de threads planifie ce thread de passer de exécutable à l'état en cours d'exécution. quand sleep()est appelé sur le thread, il passe de l'état d'exécution à l'état d'attente et peut revenir à l'état d'exécution lorsque le temps de veille est écoulé.

En cas d'appel depuis un bloc synchronisé: lorsque la wait()méthode est appelée, le thread quitte le verrou de l'objet. Mais la sleep()méthode lorsqu'elle est appelée à partir d'un bloc synchronisé ou d'un thread de méthode ne laisse pas le verrou d'objet.

Pour plus de référence

Depuis la page de documentation d'Oracle sur la méthode wait () de Object:

public final void wait()

1. Force le thread actuel à attendre qu'un autre thread appelle la notify()méthode ou la notifyAll()méthode pour cet objet. En d'autres termes, cette méthode se comporte exactement comme si elle exécutait simplement l'appel wait(0).
2. Le thread actuel doit posséder le moniteur de cet objet. Le thread libère la propriété de ce moniteur et attend qu'un autre thread notifie aux threads en attente de réveil sur le moniteur de cet objet
3. des interruptions et des réveils parasites sont possibles
4. Cette méthode ne doit être appelée que par un thread propriétaire du moniteur de cet objet

Cette méthode jette

1. IllegalMonitorStateException - si le thread actuel n'est pas le propriétaire du moniteur de l'objet.

2. InterruptedException- si un thread a interrompu le thread actuel avant ou pendant que le thread actuel attendait une notification. Le statut interrompu du thread actuel est effacé lorsque cette exception est levée.

Depuis la page de documentation d'Oracle sur la méthode de Threadclasse sleep () :

public static void sleep(long millis)

1. Provoque la mise en veille du thread en cours d'exécution (arrête temporairement l'exécution) pendant le nombre de millisecondes spécifié, sous réserve de la précision et de l'exactitude des temporisateurs et des planificateurs du système.
2. Le thread ne perd la propriété d'aucun moniteur.

Cette méthode lance:

1. IllegalArgumentException - si la valeur de millis est négative

2. InterruptedException- si un thread a interrompu le thread actuel. Le statut interrompu du thread actuel est effacé lorsque cette exception est levée.

Autre différence clé:

wait()est une méthode non statique (méthode d'instance) contrairement à la méthode statique sleep()(méthode de classe).

wait()est donné à l'intérieur d'une méthode synchronisée alors qu'il sleep()est donné à l'intérieur d'une méthode non synchronisée car la wait()méthode libère le verrou sur l'objet mais sleep()ou yield()libère le lock().

• La méthode wait(1000)fait dormir le thread actuel jusqu'à une seconde .
  • Un thread peut dormir moins de 1 seconde s'il reçoit l' appel de méthode notify()ornotifyAll() .
• L'appel à sleep(1000)provoque la mise en veille du thread actuel pendant exactement 1 seconde .
  • De plus, le fil dormant ne maintient pas le verrouillage d'une ressource . Mais le fil d'attente le fait.

En fait, tout cela est clairement décrit dans les documents Java (mais je ne l'ai réalisé qu'après avoir lu les réponses).

http://docs.oracle.com/javase/8/docs/api/index.html :

wait () - Le thread actuel doit posséder le moniteur de cet objet. Le thread libère la propriété de ce moniteur et attend qu'un autre thread notifie aux threads en attente sur le moniteur de cet objet de se réveiller via un appel à la méthode notify ou à la méthode notifyAll. Le thread attend ensuite jusqu'à ce qu'il puisse récupérer la propriété du moniteur et reprendre l'exécution.

sleep () - Fait dormir le thread en cours d'exécution (arrête temporairement l'exécution) pendant le nombre de millisecondes spécifié, sous réserve de la précision et de l'exactitude des temporisateurs et des planificateurs du système. Le thread ne perd la propriété d'aucun moniteur.