Unterschied zwischen “wait()” und “sleep()” in Java
Lesezeit: 7 Minuten
Aussenseiter
Was ist der Unterschied zwischen a wait() und sleep() in Threads?
Verstehe ich, dass a wait()-ing Thread befindet sich noch im Ausführungsmodus und verwendet CPU-Zyklen, aber a sleep()-ing verbraucht keine CPU-Zyklen, richtig?
Warum haben wir beidewait() und sleep()?
Wie unterscheidet sich ihre Umsetzung auf einer niedrigeren Ebene?
sehr gute frage. Semantik von beiden ist leicht zu verwechseln.
– Andreas Petersson
24. Juni 2009 um 7:25 Uhr
Sehr schöne Fragen, aber sie sind 2 in einem. Warum wir beide haben, ist nicht dasselbe wie wie sie auf einer niedrigeren Ebene implementiert werden können (und nicht sind!). Darauf habe ich auch geantwortet.
– estani
19. April 2012 um 10:39 Uhr
Angenommen, ein Thread A befindet sich in einem synchronisierten Block, und während er sich in der CPU befindet, wird dieser Thread von diesem Thread genommen und an einen anderen Thread B übergeben. Nun, in welchen Zustand Thread A gehen wird, werden die anderen Threads, die auf diesen synchronisierten Block warten, jetzt hineinkommen ?
es ist GENAU das Gegenteil – sleep “benutzt” alle verfügbaren CPU-Zyklen, aber da sich der Thread im “WAITING”-Zustand befindet, können diese bei Bedarf nachgegeben werden – tatsächlich geben die meisten Betriebssysteme die Zyklen automatisch nach WENN es ist möglich, daher wird Ihr Thread keine tatsächliche CPU-Last erzeugen … aber auf älteren Betriebssystemen. Object.wait() hingegen NOCH NIE verwendet beliebige Zyklen (während er nicht benachrichtigt wird), da dies in vielen Fällen über Software-Interrupts realisiert wird – private, vorübergehende und transparente Sperren, die von der JVM implementiert werden. Thread.sleep ist eine schlechte Übung.
– spezialist
1. Dezember 2014 um 11:16 Uhr
Robert Munteanu
Ein wesentlicher Unterschied, der noch nicht erwähnt wurde, ist folgender:
sleep() tut nicht Lösen Sie die Sperre, die es auf dem Thread hält,
synchronized(LOCK) {
Thread.sleep(1000); // LOCK is held
}
wait()Freigaben die Sperre, die es für das Objekt hält.
synchronized(LOCK) {
LOCK.wait(); // LOCK is not held
}
Das Warten gibt nur die Sperre für das Objekt frei, das Sie haben Anruf warte() an. Es gibt keine frei Sonstiges Schlösser.
– Jon Skeet
24. Juni 2009 um 7:18 Uhr
Sie müssen den Schlafmodus nicht innerhalb einer Sperre aufrufen – Sperren und Warten/Benachrichtigen gehen Hand in Hand, aber Sperren und Schlafen haben nichts miteinander zu tun.
– oxbow_lakes
24. Juni 2009 um 7:21 Uhr
@oxbow_lakes – Ich würde sagen, dass Sie nicht mit Schlössern schlafen sollten, dafür gibt es nur wenige Anwendungsfälle. Wollte nur auf die Unterschiede hinweisen.
– Robert Munteanu
24. Juni 2009 um 7:23 Uhr
@RobertMunteanu, Ihre Antwort behauptet das irreführend sleep hält Java sperrt, tut es aber nicht. Um einen fairen Vergleich zu haben, würden wir vergleichen synchronized(OUTER_LOCK){ Thread.sleep(1000); } mit synchronized(OUTER_LOCK){ synchronized(LOCK){LOCK.wait();} } und wir können sehen, dass beide Anweisungen die nicht freigeben OUTER_LOCK. Wenn es einen Unterschied gibt, können wir das sagen sleep nicht explizit verwendenJava Sperren, aber die Frage lautet: “Wie variiert ihre Implementierung auf einer niedrigeren Ebene?” unquote.
– Schrittmacher
11. August 2014 um 7:56 Uhr
@Pacerier wait() ist in Ihrem Codebeispiel mit der Bedingung der innersten Sperre verknüpft, von der aus sie aufgerufen wird. wait() kann nur freigeben LOCK und nicht OUTER_LOCK. So ist der Java-Monitor sowieso aufgebaut. Ein fairer Vergleich wäre synchronized(OUTER_LOCK){ synchronized(LOCK) { Thread.sleep(1000); } } und synchronized(OUTER_LOCK){ synchronized(LOCK) { LOCK.wait(); } }. In diesem Fall sleep() hält beide Sperren während wait() wird veröffentlicht LOCK aber halt noch OUTER_LOCK
die Erklärung von sleep(n) sagt implizit, dass der aktuell laufende Thread den Monitor der Sperre freiwillig aufgibt, was ist nicht wahr. Zitat aus Javadoc des Threads:”Der Thread verliert nicht den Besitz von Monitoren.”
– Clint Eastwood
29. April 2015 um 1:09 Uhr
@Jonathan In der Antwort werden Monitore nicht erwähnt, und das liegt daran sleep hat kein besonderes Verhalten in Bezug auf monitor als jeder andere Java-Methodenaufruf, d. h. es interagiert oder modifiziert sie in keiner Weise. Wenn Sie etwas über Monitore sagen würden, sollten Sie das angeben wait wird zusätzlich zu den oben genannten Dingen vorübergehend die Sperre für das aufgerufene Objekt aufgeben.
– pqnet
3. Juli 2015 um 11:20 Uhr
@Erich, benutze wait(n) zu vergleichen sleep(n). Es macht keinen Sinn, den No-Arg-Wert zu vergleichen.
– Schrittmacher
9. Mai 2020 um 14:40 Uhr
estan
Hier gibt es viele Antworten, aber ich konnte die erwähnte semantische Unterscheidung auf keiner finden.
Es geht nicht um den Thread selbst; beide Methoden sind erforderlich, da sie sehr unterschiedliche Anwendungsfälle unterstützen.
sleep() sendet den Thread wie zuvor in den Ruhezustand, er packt nur den Kontext und stoppt die Ausführung für eine vordefinierte Zeit. Um es also vor der Fälligkeit aufzuwecken, müssen Sie die Thread-Referenz kennen. Dies ist keine übliche Situation in einer Umgebung mit mehreren Threads. Es wird hauptsächlich für die Zeitsynchronisierung (z. B. Aufwachen in genau 3,5 Sekunden) und/oder fest codierte Fairness (einfach eine Weile schlafen und andere Threads arbeiten lassen) verwendet.
wait(), im Gegenteil, ist ein Thread- (oder Nachrichten-) Synchronisierungsmechanismus, mit dem Sie einen Thread benachrichtigen können, für den Sie keine gespeicherte Referenz haben (noch kümmern). Sie können es sich als ein Publish-Subscribe-Muster vorstellen (wait == abonnieren und notify() == veröffentlichen). Im Grunde genommen senden Sie mit Notify () eine Nachricht (die möglicherweise überhaupt nicht empfangen wird und normalerweise ist es Ihnen egal).
Zusammenfassend verwenden Sie normalerweise sleep() zur Zeitsynchronisation u wait() für Multi-Thread-Synchronisation.
Sie könnten auf die gleiche Weise im zugrunde liegenden Betriebssystem oder überhaupt nicht implementiert werden (da frühere Versionen von Java kein echtes Multithreading hatten; wahrscheinlich tun das einige kleine VMs auch nicht). Vergessen Sie nicht, dass Java auf einer VM ausgeführt wird, sodass Ihr Code je nach VM/OS/HW, auf der es ausgeführt wird, in etwas anderes umgewandelt wird.
Hier habe ich einige wichtige Unterschiede zwischen aufgeführt wait() und sleep() Methoden. PS:Klicken Sie auch auf die Links, um den Bibliothekscode anzuzeigen (interne Funktionsweise, spielen Sie zum besseren Verständnis einfach ein wenig herum).
wait() ist die nicht statische Methode – public final void wait() throws InterruptedException { //...}
wait() sollte per benachrichtigt werden notify() oder notifyAll() Methoden.
wait() -Methode muss aus einer Schleife aufgerufen werden, um mit Fehlalarmen umzugehen.
wait() Die Methode muss aus dem synchronisierten Kontext (dh der synchronisierten Methode oder dem Block) aufgerufen werden, andernfalls wird sie ausgelöst IllegalMonitorStateException
Code-Snippet zum Aufrufen der Wait- und Sleep-Methode
synchronized(monitor){
while(condition == true){
monitor.wait() //releases monitor lock
}
Thread.sleep(100); //puts current thread on Sleep
}
Unterschied zwischen wait() und sleep()
Der grundlegende Unterschied besteht darin wait() ist nicht statische Methode von Object und sleep() ist eine statische Methode von Thread.
Der Hauptunterschied ist das wait() gibt die Sperre während sleep() gibt während des Wartens keine Sperre frei.
wait() wird für die Inter-Thread-Kommunikation während verwendet sleep() wird im Allgemeinen verwendet, um eine Pause bei der Ausführung einzufügen.
wait() sollte von innen sync aufgerufen werden sonst bekommen wir eine IllegalMonitorStateExceptionwährend sleep() kann überall angerufen werden.
Um einen Thread neu zu beginnen wait()du musst anrufen notify() oder notifyAll() unbegrenzt. Wie für sleep(), der Thread wird definitiv nach einem bestimmten Zeitintervall gestartet.
Ähnlichkeiten
Beide machen den aktuellen Thread in den gehen Nicht lauffähig Zustand.
Beide sind einheimisch Methoden.
14088400cookie-checkUnterschied zwischen “wait()” und “sleep()” in Javayes
sehr gute frage. Semantik von beiden ist leicht zu verwechseln.
– Andreas Petersson
24. Juni 2009 um 7:25 Uhr
Sehr schöne Fragen, aber sie sind 2 in einem. Warum wir beide haben, ist nicht dasselbe wie wie sie auf einer niedrigeren Ebene implementiert werden können (und nicht sind!). Darauf habe ich auch geantwortet.
– estani
19. April 2012 um 10:39 Uhr
Angenommen, ein Thread A befindet sich in einem synchronisierten Block, und während er sich in der CPU befindet, wird dieser Thread von diesem Thread genommen und an einen anderen Thread B übergeben. Nun, in welchen Zustand Thread A gehen wird, werden die anderen Threads, die auf diesen synchronisierten Block warten, jetzt hineinkommen ?
– Petrus
17. August 2013 um 8:22 Uhr
Hier ist ein guter Artikel, der es beschreibt: qat.com/using-waitnotify-instead-thread-sleep-java
– Rocky Riemenscheibe
27. September 2013 um 13:59 Uhr
es ist GENAU das Gegenteil – sleep “benutzt” alle verfügbaren CPU-Zyklen, aber da sich der Thread im “WAITING”-Zustand befindet, können diese bei Bedarf nachgegeben werden – tatsächlich geben die meisten Betriebssysteme die Zyklen automatisch nach WENN es ist möglich, daher wird Ihr Thread keine tatsächliche CPU-Last erzeugen … aber auf älteren Betriebssystemen. Object.wait() hingegen NOCH NIE verwendet beliebige Zyklen (während er nicht benachrichtigt wird), da dies in vielen Fällen über Software-Interrupts realisiert wird – private, vorübergehende und transparente Sperren, die von der JVM implementiert werden. Thread.sleep ist eine schlechte Übung.
– spezialist
1. Dezember 2014 um 11:16 Uhr