Thread isInterrupt

[Leyla]

Folgender Code gegeben:

public void run() {
    while (!(Thread.currentThread().isInterrupted())) {
        try {
             Thread.sleep(2000);
            } catch (InterruptedException e) {
             this.interrupt();
            }
    }
}

Meine Frage ist, warum muss man "this.interrupt()" ausführen, wenn der Thread durch Thread.sleep() bereits unterbrochen wird. Und gehen wir mal davon aus in Thread.sleep() tritt eine InterruptedException auf. Wieso muss man den Thread dann noch mit interrupt beenden, wenn ja schon der Thread interrupted ist?

 

[Marinek]

Was genau macht denn diese Methode bei dir?

Du bist ja vermutlich in einer Runable ... Diese hat keine interupt() Methode.

 

[Leyla]

Aber diese kann man dort ausführen die Methode soll nichts bestimmtes machen es geht da nur um das Verständnis

 

[KonradN]

Die Frage ist aber doch, was das für eine Methode interrupt() ist.

Habt Ihr evtl. von Thread geerbt? Dann wäre es diese Methode:
Thread (Java SE 17 & JDK 17) (oracle.com)

Interrupts this thread.
Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown.
If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int) methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.
If this thread is blocked in an I/O operation upon an InterruptibleChannel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException.
If this thread is blocked in a Selector then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's wakeup method were invoked.
If none of the previous conditions hold then this thread's interrupt status will be set.
Interrupting a thread that is not alive need not have any effect.

Und hier sollte der Punkt "If none of the previous conditions hold then this thread's interrupt status will be set." der wichtige sein. Es wird also durch diesen Aufruf der interrupt status gesetzt. Du kannst also über isInterrupted() abfragen, ob der Thread unterbrochen wurde. Das kann evtl. interessant sein, weil Du dann eine Schleife verlassen willst oder so (Was man aber auch in dem catch Block machen könnte...).

Aber wenn man einen neuen Thread erstellt, dann ist es eher unüblich, von Thread zu erben. Statt dessen wird Runnable implementiert.
Und die Gedanken von mir sind natürlich nur valide, wenn Du von Thread erbst. Wenn Du nicht von Thread erbst, dann musst Du schauen, was Du für eine Methode interrupt Du hast. Denn da kann es folgende Fälle geben:

• Du hast die Methode in der Klasse geschrieben - dann schau an, was sie macht und gut ist es.
• Du erbst von etwas, das diese Methode implementiert - dann schau Dir das an über Dokumentation oder den Source.
• Du bekommst evtl. auch einfach einen Compile Fehler, weil es die Methode nicht gibt.

Ohne Details können wir aber nur raten - daher ist es an Dir, da Details zu nennen. Wir können da sonst nur raten.

 

[Hough]

Folgender Code gegeben:

public void run() {
    while (!(Thread.currentThread().isInterrupted())) {
        try {
             Thread.sleep(2000);
            } catch (InterruptedException e) {
             this.interrupt();
            }
    }
}

Meine Frage ist, warum muss man "this.interrupt()" ausführen, wenn der Thread durch Thread.sleep() bereits unterbrochen wird. Und gehen wir mal davon aus in Thread.sleep() tritt eine InterruptedException auf. Wieso muss man den Thread dann noch mit interrupt beenden, wenn ja schon der Thread interrupted ist?

Muß man nicht. Wenn du in Zeile 6 den Thread beenden möchtest, kannst du dort auch ein return oder ein break schreiben.

 

[KonradN]

Muß man nicht. Wenn du in Zeile 6 den Thread beenden möchtest, kannst du dort auch ein return oder ein break schreiben.

Thread.interrupt() beendet den Thread nicht.

 

[Hough]

Thread.interrupt() beendet den Thread nicht.

Stimmt. Danke für die Ergänzung.

 

[Leyla]

Die Frage ist aber doch, was das für eine Methode interrupt() ist.

Habt Ihr evtl. von Thread geerbt? Dann wäre es diese Methode:
Thread (Java SE 17 & JDK 17) (oracle.com)

Und hier sollte der Punkt "If none of the previous conditions hold then this thread's interrupt status will be set." der wichtige sein. Es wird also durch diesen Aufruf der interrupt status gesetzt. Du kannst also über isInterrupted() abfragen, ob der Thread unterbrochen wurde. Das kann evtl. interessant sein, weil Du dann eine Schleife verlassen willst oder so (Was man aber auch in dem catch Block machen könnte...).

Aber wenn man einen neuen Thread erstellt, dann ist es eher unüblich, von Thread zu erben. Statt dessen wird Runnable implementiert.
Und die Gedanken von mir sind natürlich nur valide, wenn Du von Thread erbst. Wenn Du nicht von Thread erbst, dann musst Du schauen, was Du für eine Methode interrupt Du hast. Denn da kann es folgende Fälle geben:

• Du hast die Methode in der Klasse geschrieben - dann schau an, was sie macht und gut ist es.
• Du erbst von etwas, das diese Methode implementiert - dann schau Dir das an über Dokumentation oder den Source.
• Du bekommst evtl. auch einfach einen Compile Fehler, weil es die Methode nicht gibt.

Ohne Details können wir aber nur raten - daher ist es an Dir, da Details zu nennen. Wir können da sonst nur raten.

Genau das meine ich. Es geht um eine beliebige Klasse die von Thread erbt.

Genau das verstehe ich nicht. Wenn Threads.sleep eine InterruptedException wirft, dann ist der Threads doch eigentlich unterbrochen worden. Meine Frage ist daher warum man noch explizit this.interrupt ausführen muss

 

[Marinek]

Aber diese kann man dort ausführen die Methode soll nichts bestimmtes machen es geht da nur um das Verständnis

Verstehe nicht, warum die Methode nicht einfach gepostet wird.

Leute raten doch hier nur rum.

 

[KonradN]

Genau das verstehe ich nicht. Wenn Threads.sleep eine InterruptedException wirft, dann ist der Threads doch eigentlich unterbrochen worden. Meine Frage ist daher warum man noch explizit this.interrupt ausführen muss

Wenn Du einen Thread hast, der lange oder gar unbegrenzt läuft, dann willst Du den oft einen Mechanismus haben, diesen von außen anhalten zu können. Dazu hat Thread interrupt() und isInterrupted(). Du kannst also im Thread regelmäßig prüfen, ob der Thread unterbrochen wurde oder nicht.

Die Frage ist aber, wie dieses Flag gesetzt werden kann. Und da kommt man auf interrupt(). Da muss man dann die Dokumentation lesen um das Verhalten zu verstehen und ich habe diese ja schon gebracht. Wenn ein Thread in einem sleep ist (und bei ein paar anderen Dingen), dann wird dieses Flag aber nicht gesetzt:

If this thread is blocked in an invocation of the .... sleep(long), or sleep(long, int) methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.

"then its interrupt status will be cleared and it will receive an InterruptedException" ==> Der Thread ist also nicht markiert als interrupted. Damit man diese Unterbrechung aber noch nachvollziehen kann, wird der Status durch den Aufruf von interrupt() gesetzt. Damit ist auch im Anschluss noch bekannt, dass der Thread unterbrochen wurde.
Ohne diesen Aufruf könnte man nach dem Block nicht sagen, ob der sleep komplett durchgelaufen wurde oder ob es ein Signal von außen gab zur Unterbrechung.

 

[Blender3D]

Meine Frage ist, warum muss man "this.interrupt()" ausführen, wenn der Thread durch Thread.sleep() bereits unterbrochen wird.

Man muss das nicht tun. Bei einem interrupt des Threads wird das Interrupt Flag auf false gesetzt. Durch den weiteren aufruft der Methode interrupt wird das Flag wieder auf true gesetzt. Und es kann dadurch an anderer Stelle kenntlich gemacht werden.
https://www.baeldung.com/java-interrupted-exception

 

[Nouser]

In der Konstellation mußt du nur irgendetwas machen um bei einem Interrupt Signal aus dem while loop zu kommen.
Wird sleep unterbrochen, löscht es den interrupted status und wirft eine Exception. Im catch block willst du nun den loop irgendwir verlassen. Das kannst du, indem du (wie schon erwähnt) break ausführst oder den interrupted status wieder setzt, so daß die Abbruchbedingung im Kopf der while-Schleife erfüllt ist.

Alternativ tauscht du einfach das try-catch / while nesting (try umschließt while). Wird sleep unterbrochen, dann ist der catch block außerhalb der Schleife und es geht einfach im Code weiter.

 

[Leyla]

In der Konstellation mußt du nur irgendetwas machen um bei einem Interrupt Signal aus dem while loop zu kommen.
Wird sleep unterbrochen, löscht es den interrupted status und wirft eine Exception. Im catch block willst du nun den loop irgendwir verlassen. Das kannst du, indem du (wie schon erwähnt) break ausführst oder den interrupted status wieder setzt, so daß die Abbruchbedingung im Kopf der while-Schleife erfüllt ist.

Alternativ tauscht du einfach das try-catch / while nesting (try umschließt while). Wird sleep unterbrochen, dann ist der catch block außerhalb der Schleife und es geht einfach im Code weiter.

Genau da liegt mein Verständnisproblem.

Schritt 1: Thread wird gestartet.
Status von isInterrupted = false;

Schritt 2: In Try-Catch wird durch Thread.sleep eine Exception geworfen
Status von Status von isInterrupted = true;

Jetzt verstehe ich nicht warum es noch ein .interrupt() geben muss, wenn der Status jetzt schon auf true ist. Weil man dadurch ja schon aus der Schleife geht

 

[Marinek]

Jetzt verstehe ich nicht warum es noch ein .interrupt() geben muss, wenn der Status jetzt schon auf true ist. Weil man dadurch ja schon aus der Schleife geht

Poste doch mal die Methode.

Was macht sie.

 

[Nouser]

Genau da liegt mein Verständnisproblem.

Konrad hat oben schon die Docs zu sleep(long) verlinkt.

InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.

Heißt also z.B,

• du setzt das interrupted flag.
• sleep() prüft, ob das interrupted flag gesetzt ist, wenn ja, wird das flag gelöscht und eine InterruptedException ausgelöst.
• wenn du nun im catch block das flag nicht erneut setzt (mit Thread.interrupt()), ist auch die Schleifenbedingung weiterhin erfüllt und sie wird nicht abgebrochen.

sleep() setzt also den interrupted status wieder zu false und du gehst einfach von einer falschen Annahme aus.

 

[Leyla]

Poste doch mal die Methode.

Was macht sie.

Die kannst du doch in der Java-Dokumentation lesen. https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html

 

[Leyla]

Konrad hat oben schon die Docs zu sleep(long) verlinkt.

Heißt also z.B,

• du setzt das interrupted flag.
• sleep() prüft, ob das interrupted flag gesetzt ist, wenn ja, wird das flag gelöscht und eine InterruptedException ausgelöst.
• wenn du nun im catch block das flag nicht erneut setzt (mit Thread.interrupt()), ist auch die Schleifenbedingung weiterhin erfüllt und sie wird nicht abgebrochen.

Was heißt hier genau "flag gelöscht" ?

 

[Nouser]

Was heißt hier genau "flag gelöscht" ?

Wie das genau umgesetzt wird ist Sache der JVM. Stell es dir als

boolean interrupted;

in der Thread Klasse vor.

rufst du Thread.interrupt() auf, dann wird das boolean zu true gesetzt. sleep() checkt nun immer mal wieder, ob das interrupt flag gesetzt ist (das Boolean true ist), und wenn ja, löscht das flag, setzt es also wieder zu false und wirft die InterruptedExeption.

Das ist schon alles.

 

[bibber]

Gesehen? https://stackoverflow.com/questions...n-thread-interrupted-and-thread-isinterrupted

Ein weiterer Unterschied ist, dass interrupted() auch den Status des aktuellen Threads löscht. Mit anderen Worten: Wenn Sie die Funktion zweimal hintereinander aufrufen und der Thread zwischen den beiden Aufrufen nicht unterbrochen wird, gibt der zweite Aufruf false zurück, selbst wenn der erste Aufruf true zurückgegeben hat.

Alles weitere steht dann in den Javadocs dazu.