Schleife in Java stoppen

Question

Ich verwende einen Thread, der kontinuierlich aus einer Warteschlange liest.

Etwas wie:

public void run() { 
    Object obj; 
    while(true) { 
     synchronized(objectsQueue) { 
      if(objectesQueue.isEmpty()) { 
       try { 
        objectesQueue.wait(); 
       } catch (InterruptedException e) { 
        e.printStackTrace(); 
       } 

       obj = objectesQueue.poll(); 
      } 
     } 

     // Do something with the Object obj 
    } 
} 

Was ist der beste Weg, um diesen Thread zu stoppen?

Ich sehe zwei Möglichkeiten:

1 - Da Thread.stop() veraltet ist, kann ich eine stopThisThread() Methode implementieren, die eine n Atom-Check-Zustandsgröße verwendet.

2 - Senden Sie ein Death Event-Objekt oder etwas Ähnliches an die Warteschlange. Wenn der Thread ein Todesereignis abruft, wird er beendet.

Ich bevorzuge den 1. Weg, jedoch weiß ich nicht, wann die stopThisThread() Methode aufrufen, da etwas auf seinem Weg zur Warteschlange sein könnte und das Stoppsignal zuerst ankommen kann (nicht wünschenswert).

Irgendwelche Vorschläge?

Answer 1

Der Ansatz DeathEvent (oder wie es oft genannt wird, "Poison Pill") funktioniert gut, wenn Sie alle Arbeiten in der Warteschlange vor dem Herunterfahren abschließen müssen. Das Problem ist, dass dies lange dauern kann.

Wenn Sie wollen so schnell wie möglich zu stoppen, empfehle ich Ihnen dieses

BlockingQueue<O> queue = ... 

... 

public void run() { 
    try { 
     // The following test is necessary to get fast interrupts. If 
     // it is replaced with 'true', the queue will be drained before 
     // the interrupt is noticed. (Thanks Tim) 
     while (!Thread.interrupted()) { 
      O obj = queue.take(); 
      doSomething(obj); 
     } 
    } catch (InterruptedException ex) { 
     // We are done. 
    } 
} 

tun t den Faden zu stoppen, die mit dieser Methode run instanziiert, einfach t.interrupt(); nennen. Wenn Sie den obigen Code mit anderen Antworten vergleichen, werden Sie feststellen, wie die Verwendung einer BlockingQueue und Thread.interrupt() die Lösung vereinfacht.

Ich würde auch behaupten, dass eine zusätzliche stop Flag ist unnötig, und im großen Bild, potenziell schädlich. Ein gut erzogener Arbeitsthread sollte einen Interrupt berücksichtigen. Ein unerwarteter Interrupt bedeutet einfach, dass der Worker in einem Kontext ausgeführt wird, den der ursprüngliche Programmierer nicht erwartet hat. Das Beste ist, wenn der Arbeiter das tut, was ihm gesagt wird ... d. H. Er sollte aufhören ... ob das zur ursprünglichen Konzeption des Programmierers passt oder nicht.

Answer 2

Ansatz 1 ist der bevorzugte Ansatz.

Setzen Sie einfach ein flüchtiges stop Feld auf True und rufen Sie auf dem laufenden Thread. Dadurch werden alle E/A-Methoden, die auf die Rückgabe warten, mit InterruptedException erzwungen (und wenn Ihre Bibliothek korrekt geschrieben ist, wird dies ordnungsgemäß gehandhabt).

Answer 3

Ich denke, Ihre beiden Fälle zeigen tatsächlich das gleiche potenzielle Verhalten. Für den zweiten Fall wird in Thread A das DeathEvent hinzugefügt, nach dem Thread B ein FooEvent hinzufügt. Wenn dein Job-Thread das DeathEvent empfängt, ist immer noch ein FooEvent dahinter, das gleiche Szenario, das du in Option 1 beschreibst, es sei denn, du versuchst die Warteschlange vor der Rückkehr zu löschen, aber dann hältst du den Thread am Leben versuchen zu tun ist es zu stoppen.

Ich stimme Ihnen zu, dass die erste Option wünschenswerter ist. Eine mögliche Lösung hängt davon ab, wie Ihre Warteschlange ausgefüllt ist.Wenn es ein Teil Ihrer Arbeit Thread-Klasse ist könnten Sie Ihre stopThisThread() -Methode einen Flag, das einen entsprechenden Wert (oder throw Exception) aus dem Einreihen Aufruf dh zurückkehren würde:

MyThread extends Thread{ 
    boolean running = true; 

    public void run(){ 
    while(running){ 
     try{ 
     //process queue... 
     }catch(InterruptedExcpetion e){ 
     ... 
     } 
    } 
    } 

    public void stopThisThread(){ 
    running = false; 
    interrupt(); 
    } 

    public boolean enqueue(Object o){ 
    if(!running){ 
     return false; 
     OR 
     throw new ThreadNotRunningException(); 
    } 
    queue.add(o); 
    return true; 
    } 
} 

wäre es dann die Verantwortlichkeit des Objekts, das versucht, das Ereignis in die Warteschlange einzureihen, um es angemessen zu behandeln, aber zumindest wird es wissen, dass das Ereignis nicht in der Warteschlange ist und nicht verarbeitet wird.

Answer 4

Ich habe normalerweise eine Flagge in der Klasse, die den Thread drin hat und in meinem Thread-Code würde ich tun. (HINWEIS: Statt while (true) mache ich while (flag))

Dann erstellen Sie eine Methode in der Klasse, um das Flag auf false zu setzen;

private volatile bool flag = true; 

public void stopThread() 
{ 
    flag = false; 
} 

    public void run() { 
     Object obj; 
     while(flag) { 
      synchronized(objectsQueue) { 
       if(objectesQueue.isEmpty()) { 
        try { 
         objectesQueue.wait(); 
        } catch (InterruptedException e) { 
         e.printStackTrace(); 
        } 

        obj = objectesQueue.poll(); 
       } 
      } 

      // Do something with the Object obj 
     } 
    } 

Answer 5

In Ihrem Leser Thread haben eine boolesche Variable zu stoppen. Wenn Sie möchten, dass dieser Thread stoppt, setzen Sie thius auf "true" und unterbrechen Sie den Thread. Innerhalb des Leserthreads, wenn es sicher ist (wenn Sie kein unverarbeitetes Objekt haben), überprüfen Sie den Status der Stoppvariablen und kehren Sie aus der Schleife zurück, falls gesetzt. wie unten.

public class readerThread extends Thread{ 
    private volitile boolean stop = false; 
    public void stopSoon(){ 
     stop = true; 
     this.interrupt(); 
    } 
    public void run() { 
     Object obj; 
     while(true) { 
      if(stop){ 
       return; 
      } 
      synchronized(objectsQueue) { 
      if(objectesQueue.isEmpty()) { 
       try { 
        objectesQueue.wait(); 
       } catch (InterruptedException e) { 
        e.printStackTrace(); 
       } 
       if(stop){ 
        return; 
       }  
       obj = objectesQueue.poll(); 
       // Do something with the Object obj 
      } 
     } 
    } 


} 
public class OtherClass{ 
    ThreadReader reader; 
    private void start(){ 
      reader = ...; 
      reader.start(); 
    } 

    private void stop(){ 
      reader.stopSoon(); 
      reader.join();  // Wait for thread to stop if nessasery. 
    } 
} 

Answer 6

Warum nicht einen Scheduler verwenden, den Sie bei Bedarf einfach anhalten können? Der Standard-Scheduler unterstützt wiederholte Planung, die auch darauf wartet, dass der Worker-Thread beendet wird, bevor ein neuer Lauf neu terminiert wird.

ScheduledExecutorService service = Executors.newSingleThreadScheduledExecutor(); 
service.scheduleWithFixedDelay(myThread, 1, 10, TimeUnit.SECONDS); 

Diese Probe würde den Thread mit einer Verzögerung von 10 Sekunden ausgeführt, das heißt, wenn ein Lauf beendet ist, es es 10 Sekunden später neu gestartet wird. Und anstatt das Rad neu zu erfinden, müssen Sie das Rad neu erfinden

Die while (true) ist nicht mehr notwendig.

ScheduledExecutorService Javadoc