Wie tötet man einen thread hat eine while(true)?

Ich versuche, zu schließen, alle meine Threads in meiner threadpool.

In der Regel versuche ich:

        while(!Thread.currentThread().isInterrupted()) {...

Schließen der while-Schleife...

Aber ich habe einen Thread, die nur aus über

        while(!Thread.currentThread().isInterrupted()) {//which is true

Dies ist, wie ich das schließen des threads:

pool.shutdownNow();

So, wie würden Sie schließen so einen Thread?

"&& wahr" überflüssig ist.
Sie müssen wissen, exit-Bedingung für diesen thread....
Nicht Thread.interrupt() für Sie arbeiten?
wenn Sie die oben genannten while-Schleifen in einer Methode der Klasse, die extends Thread verwenden, können Sie this.isInterrupted() statt Thread.currentThread().isInterrupted().
Hoffentlich OP nicht verlängern Thread.
Die Bedingung wird zu false, wenn Sie anrufen shutdownNow, weil diese Methode unterbricht die threads in der Schleife, und die Schleife wird verlassen. Nicht sicher, ob ich Ihre Frage verstehe.
Topolnik: Was wäre daran falsch? Ich lese mehrere tutorials über multithreading in Java, die das getan hat.
Es ist eine allgemein anerkannte beste Praxis. Einfach bei google nach "java erweitern Thread" zu finden, alles über Sie. Die tutorials sind offensichtlich tun Ihren Lesern einen Bärendienst.
Selbst die offizielle Dokumentation ist es: docs.oracle.com/javase/7/docs/api/java/lang/Thread.html
Die offizielle Dokumentation ist es nicht zu empfehlen, aber zu... naja, zu dokumentieren, in diesem Fall die Tatsache, dass es in der Tat zwei Wege, um einen Einstiegspunkt für ein Thread Instanz.

InformationsquelleAutor maximus | 2012-10-29

15

Können Sie ein volatile boolean flag.
```
public class Worker implements Runnable {

    volatile boolean cancel = false;
    @Override
    public void run() {

        while (!cancel) {
            //Do Something here
        }
    }

    public void cancel() {
        cancel = true;
    }
}
```
Jetzt können Sie nur aufrufen,
```
worker.cancel();
```
Update:

Hilfe von Java-doc von shutdownNow()

Versuche zu stoppen, alle aktiv ausgeführten Aufgaben, Stoppt die Verarbeitung der wartenden Aufgaben, und gibt eine Liste der Aufgaben, die auf Ihre Hinrichtung warteten.

hier sind keine Garantien über best-effort-versuche zu stoppen Verarbeitung aktiv ausführen von Aufgaben. Zum Beispiel, typische Implementierungen Abbrechen über Thread.interrupt(), so dass jede Aufgabe, die nicht reagieren auf interrupts kann nie kündigen.

Also entweder Sie definieren Ihre Unterbrechung-Richtlinie durch die Erhaltung der interrupts
```
  catch (InterruptedException ie) {
     //Preserve interrupt status
     Thread.currentThread().interrupt();
   }
```
- -1 Dies redundant ist - warum nicht die Unterbrechung des Mechanismus nur?
- +1 ich Frage mich das gleiche.
- Sie tun müssen, die negation in da 🙂
- Er hat ein thread die interrupt-status false, so wird es nie eingehen, während, wenn die negation es ist. Ich denke, es ist der Unterschied in der Formulierung.
- Der dir nicht folgt. (interrupt==false) => (!interrupt true), so ist die Bedingung immer wahr. OP jeden Fall leiden nicht die Schleife nie betreten wurde, aber wird nicht in der Lage, es zu brechen.
- Ja, dass wird er tun möchte, er brechen will, der thread. Sie beide haben so ein Durcheinander in meinem Kopf. 🙁
- wahre negation wahr ist, was bedeutet, dass der interrupt wird nie gesetzt zu aktuellen thread.So wollte er einen Mechanismus, wo er das tun kann.
- Der Mechanismus der Wahl wäre die Unterbrechung des Mechanismus. Thread.interrupt wird automatisch aufgerufen ExecutorService.shutdownNow().
- Ich wusste das, aber er hatte einen Fall, wo der interrupt verschluckt wurde und dann war er nicht in der Lage, das Programm zu beenden. Jetzt boolean flag ist ein weiterer exit-policy für threads. Entweder er hat interrupt() Flagge oder andere politische Entscheidung ist OP. Wir sind nicht sicher, warum die Unterbrechung geschluckt wird.
- Meiner Ansicht nach, die erste Zeile der Rat wäre "prüfen, wo es verschluckt" und nur als letzten Ausweg, Abhilfe verwenden Sie eine benutzerdefinierte Mechanismus, da diese mit viel mehr code, womit sich neue Möglichkeiten für den code zu scheitern.
InformationsquelleAutor Amit Deshpande

Statt, die man vielleicht selbst erstellt Flagge als Bedingung für die while-Schleife.

public class MyClass implements Runnable
{

    private volatile boolean running = true;

    public void stopRunning()
    {
        running = false;
    }

    public void run()
    {
        while (running)
        {

        }
        //shutdown stuff here
    }

}

Nun, um es zu stoppen, rufen Sie einfach an:

myClassObject.stopRunning();

Diese lassen den code fertig normalerweise.

Flagge muss volatile
Ja, in der Tat. Danke! Ich bearbeitete die Antwort.

InformationsquelleAutor Martijn Courteaux

2

Wenn Sie umgesetzt haben, diese wie Sie Sie beschrieben haben, es sollte einfach funktionieren.

Beim Aufruf pool.shutdownNow() es soll zu unterbrechen, alle worker-threads, die derzeit aktiv sind. Unter der Annahme, dass die Anwendung bestimmte run() Methoden überprüfen Sie die Flagge unterbrochen und beendet sich selbst, wenn Sie es finden, kann Ihr threads sollte Herunterfahren.

Es gibt wirklich keine Notwendigkeit zum hinzufügen von einem anderen Mechanismus mit einem ad-hoc - Abbrechen-flag ... oder so.

Übrigens, es gibt ein paar Gründe, warum interrupt() ist besser als ad-hoc - Stornierung:
- Standard-APIs wie ExecutorService verwenden.
- Verschiedenen low-level-API-Methoden wie sleep, wait, join und einige I/O-Methoden sind empfindlich.
InformationsquelleAutor Stephen C
1

Wenn Sie eine java.util.concurrent ExecutorService Umsetzung, dann wird es definitiv senden Sie eine interrupt signal an alle threads in der thread-pool. Das problem mit deinem rogue Aufgabe kann sein, dass die Schleife nicht in der Tat Durchlaufen, aber Blöcke, die irgendwo im Rahmen, also die interrupted status wird nicht immer überprüft.

Noch ein weiteres problem, das Sie haben können: die while-Schleife ausgeführt, einige code, der fängt InterruptedException ohne handling es richtig, effektiv schlucken das interrupt-signal. Dies ist eine gemeinsame Codierung Fehler und in den meisten Fällen, aufgrund der hässliche Wahrheit, dass InterruptedException überprüft.
- +1 nicht sicher, warum jeder will, um mit booleschen flags, die heute...
- Heh heh, und nicht nur heute 🙂
InformationsquelleAutor Marko Topolnik

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.