Thread beenden in Java

[Ahnungsloser (Gast)]

Hallo zusammen.

Ich habe folgendes Problem: Ich kann zwar in Java einen Thread starten, 
aber irgendwie nicht beenden. Er läuft trotz stop(), interrupt() u.ä. 
einfach weiter.

Könntet ihr mir helfen?

Hier der gekürzte Code:

 
 Thread test_thread = new Thread (.....);
 ..
 
 
 if(e.getSource() == btn_ein)
 {
   test_thread.start();
 }
 
 
 if(e.getSource() == btn_aus)
 {
   test_thread.interrupt();   // ??? funktioniert nicht, Thread läuft weiter!   
 }

Vielen Dank!

[Kaj (Gast)]

http://stackoverflow.com/questions/671049/how-do-you-kill-a-thread-in-java

[Boris O. (bohnsorg)]

Das Innenleben des Threads ist wichtig. Wenn da in der run-Methode 
steht:

while(true) {
  try {
    int i++;
  } catch (Exception ex) {
  }
}

Läuft das natürlich immer. Die InterruptedException, ausgelöst durch 
Thread.interrupt, wird einfach verschluckt und es gibt keinen Grund, 
warum die run-Methode zum Ende kommen sollte.

[Ahnungsloser (Gast)]

Hi Boris,

ja in der Tat, im Thread selbst ist folgendes geschrieben:

public void run() 
  {
    
    while(true)
    { ... }
        }

Das heißt ich frage in der While-Schleife ab, ob ein gewisses Flag 
gesetzt wird, welches ich dann über eine Variable von "außen" (über das 
Objekt) setze?

Oder wie würde man es am besten machen? Denn die Endlos-Schleife brauche 
ich definitiv bis zu dem Zeitpunkt, wo eben der Thread beendet werden 
soll.

Danke!

[Der Andere (Gast)]

Ahnungsloser schrieb:
> test_thread.start();

Macht man eigentlich nur mit Threads die sich selbst beenden.

Für Threads hast du eigentlich 2 verschiedene Anwendungen

1. Du willst eine Arbeit parallelisieren. Dann musst du auch die 
Ergebnisse zurückbringen und alles synchronisieren.
Dazu solltest du dir Thread Pools anschauen Package: 
java.util.concurrent

2. Du brauchst einen unabhängigen Hintergrundprozess, der undefiniert 
lange läuft. Du implementierst dazu eine eigene Klasse die entweder von 
Thread erbt oder ein entsprechendes Interface implementiert.
Zusätzlich baust du eine Methode ein, die über ein Flag dem Thread 
signalisieren kann dass er sich beenden soll.
In der Hauptschleife des Threads prüfst du regelmäßig auf das Flag und 
beendest dann ggf. die Schleife. Gesetzt wird das Flag vom 
Hauptprogramm, das den Thread instanziiert und gestartet hat.

[Basti (Gast)]

Nicht die while schleife ist das Problem, sondern der try/catch block. 
Der fängt die Exception ab/weg, die den Thread sonst beenden würde.

[Der Andere (Gast)]

Ahnungsloser schrieb:
> public void run()
>   {
>
>     while(true)
>     { ... }
>         }

stell dich doch nicht so an:

class MyThread extends Thread {
...

  boolean endThread = false;

  public void setEndThread() {
    endThread = true;
  }

  public void run() {

    while (!endThread) {
      ...
    }
  }
}

[Der Andere (Gast)]

Basti schrieb:
> Nicht die while schleife ist das Problem, sondern der try/catch block.
> Der fängt die Exception ab/weg, die den Thread sonst beenden würde.

Das ist trotzdem die Brachialmethode mit der Brechstange.

[Der Andere (Gast)]

Kleines Tutorial dazu:
http://tutorials.jenkov.com/java-concurrency/creating-and-starting-threads.html

[Ahnungsloser (Gast)]

Super, danke, das werde ich gleich mal probieren.
Habe jetzt eine public boolean-Variable in meiner Threadklasse 
implementiert, die dann als Flag von außen schaltbar sein soll und die 
While-Schleife in der Threadklasse beeinflusst.

Jetzt habe ich aber das nächste Problem.
Die Instanziierung erfolgt bei mir über folgenden Befehl:

failure_handling = new Thread(new Failure_Msg_Thread(...) )

Die besagte Boolean-Variable liegt in "Failure_Msg_Thread".
Jetzt müsste ich aber ja ein Objekt von "Failure_Msg_Thread" erzeugen, 
um auf die Boolean-Variable zuzugreifen.
Wie kann ich das tun, damit ein Bezug zu failure_handling existiert und 
somit der richtige Thread beendet wird?

Danke!

[Der Andere (Gast)]

Ahnungsloser schrieb:
> Jetzt müsste ich aber ja ein Objekt von "Failure_Msg_Thread" erzeugen,
> um auf die Boolean-Variable zuzugreifen.

Was denkst du machst du mit:

Ahnungsloser schrieb:
> new Failure_Msg_Thread(...)

Also schreib das halt in zwei Zeilen und merk dir das Objekt.

[c.m. (Gast)]

du machst eine liste mit thread objekten, und greifst vom hauptprogramm 
aus auf die getter- und setter methoden der threads in der liste zu.
ob die dazu "synchronized" sein müssen (sollten) weiß ich jetzt grad 
nicht :/

[Der Andere (Gast)]

c.m. schrieb:
> du machst eine liste mit thread objekten

Er hat EINEN zusätzlichen Thread.

[Ahnungsloser (Gast)]

>Was denkst du machst du mit:

Naja ich übergebe dem Konstruktor von Thread ein Objekt, das 
"Failure_Msg_Thread" heißt.
In der Klasse Failure_Msg_Thread ist die besagte Variable, aber ich habe 
vom Objekt "failure_handling" keinen Zugriff darauf.
Ein Objekt von "Failure_msg_Thread" habe ich ja quasi nicht.

Oder irre ich?

[Der Andere (Gast)]

Ahnungsloser schrieb:
> failure_handling = new Thread(new Failure_Msg_Thread(...) )

Sehe ich jetzt erst.

Was soll das?
Ich denke FailureMsgThread() ist abgeleitet von Thread.

Also heisst das
Thread failureHandling = new FailureMsgThread(...);
...
failureHandling.start();

...

// Am Ende:
failureHandling.setEndThread();   // oder wie auch immer du das FLag 
setzt

// jetzt noch etwas warten oder prüfen ob der Thread beendet ist

..


Irgendwie fehlen dir alle Grundlagen. Bevor du multithreaded 
programmierst solltest du die ersten 5 Kapitel von "Java ist auch eine 
Insel" mal durchgelesen und erst mal einfache Programme programmiert 
haben.

Und gewöhne dir bitte die Unterstriche ab und benutze die in Java 
übliche Notationskonventionen für Methoden, Klassen, Variablen und 
Konstanten.

[Der Andere (Gast)]

Ach Mist muss natürlich heissen:

FailureMsgThread failureHandling = new FailureMsgThread(...);

heissen, sonst kommst du nicht an die spezifischen Methoden der 
abgeleiteten Klasse.

[Ahnungsloser (Gast)]

>Thread failureHandling = new FailureMsgThread(...);

Das funktioniert bei mir schon gleich garnicht..es müsste doch wenn dann
>Failure_Msg_Thread failure_handling = new Failure_Msg_Thread
lauten?!

[Jay (Gast)]

Etwas moderner (ok, das Konzept stammt schon aus Anfang der 90er oder 
früher, aber Java hat es spät implementiert) ist es Futures zu 
verwenden.

Leider ist die JavaDoc dafür ziemliche mies

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html

und sowohl die Implementierung also auch die Beispiele die man in 
diversen Tutorien findet verschleiern die Idee mehr als das sie die 
Vorteile zeigen.

Eigentlich geht es um die Idee der Active Objects. Das ist eine Technik 
um Concurrent Programme zu strukturieren. Ein Future ist dabei nur ein 
Hilfsmittel, ein Versprechen (ein Platzhalter) auf ein Ergebnis, das ein 
(Active) Object irgendwann mal liefert. Ein Active Object ist ein 
Objekt, das intern einen oder mehrere Threads verwendet, aber seine 
Außenwelt nicht mit Thread-Details behelligt. D.h. es enkapsuliert 
Threads und regelt alle Thread-Operationen wie Synchronisation, 
Schedulling alleine. Im Gegensatz zu normalen Threads läuft ein Thread 
nicht wild über Objektgrenzen hinweg (wenn man es nicht verpfuscht) und 
Thread-Code ist nicht über die ganze Codebasis verschmiert.

Damit verbunden ist die Idee des asynchronen Methodenaufrufs (hat Booch 
glaube ich schon in den 80ern in seine OO-Methode). Methoden liefern 
nicht sofort ein Ergebnis, sonder verhalten sich asynchron. Sie liefern 
nur ein Versprechen auf ein Ergebnis (ein Future). Der Aufrufer kann das 
eigentliche Ergebnis vom Future erfragen wenn er es benötigt. Das sollte 
der Aufrufer so spät wie möglich machen, um dem Active Object genug Zeit 
zur Berechnung zu geben. In der Zwischenzeit kann der Aufrufer etwas 
anderes machen.


Das Konzept sieht so aus (Code sieht durch die println()s schlimmer aus 
als er ist):

import java.util.concurrent.Callable;
import java.util.concurrent.CancellationException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.FutureTask;

/**
 * Benutzer eines {@link ActiveObject}, der von den Thread-Details
 * nichts wissen will oder muss.
 */
public class Caller {
   private static final String myName = Caller.class.getSimpleName();

  public void foo() {
    ActiveObject activeObject = new ActiveObject();

    //
    // Asynchroner Methodenaufruf.
    // Liefert kein Ergebnis, sondern ein Versprechen auf ein
    // Ergebnis in der Zukunft.
    //
    System.out.println(myName + ": Calling Method");
    System.out.flush();
    Future<Integer> future = activeObject.asyncMethod();
    System.out.println(myName + ": Got future");
    System.out.flush();

    //
    // ... Mach irgendwas anderes ...
    //
    try {
      Thread.sleep(2000);
    } catch (InterruptedException e) {
    }

    //
      // An einem Punkt wird entweder das Ergebnis benötigt,
    // oder es kann weggeworfen werden.
    //
    boolean needResult = true; //

    if (needResult) {
      try {
        System.out.println(myName + ": Asking for result");
        System.out.flush();
        int result = future.get();
        System.out.println(myName + ": Got result: " + result);
        System.out.flush();
      } catch (Exception e) {
        System.err.println(e);
      }
    } else {
      future.cancel(true);
      System.out.println(myName + ": Result canceled");
      System.out.flush();
    }
  }

  public static void main(String[] args) {
    new Caller().foo();
  }
}

/**
 * Aktives Object. Benutzt intern Threads, behelligt den Aufrufer aber nicht mit
 * Details. Methoden liefern statt dessen Ergebnisse asynchron zum Aufruf.
 */
class ActiveObject {
  private static final String myName = ActiveObject.class.getSimpleName();

  /** Interne Threads des {@link ActiveObject} */
  private ExecutorService executorS = Executors.newFixedThreadPool(5);

  /**
   * Asynchrone Methode. Kehrt zurueck bevor das Ergebnis berechnet ist.
   * 
   * @return Ein Versprechen (Future) auf das Ergebnis in der Zukunft.
   */
  public Future<Integer> asyncMethod() {

    Callable<Integer> callable = new Callable<Integer>() {

      /**
       * Eigentliche Implementierung der Methode
       */
      @Override
      public Integer call() throws Exception {
        int i;
        for (i = 0; i < 50; i++) {
          Thread.sleep(100);
          if (Thread.interrupted()) {
            System.out.println(myName + ": Interrupted");
            System.out.flush();
            // Wahrscheinlichster Grund is Aufruf von cancel(true)
            throw new CancellationException();
          }
          System.out.println(myName + ": " + i);
          System.out.flush();
        }
        return i;
      }

    };

    FutureTask<Integer> futureTask = new FutureTask<>(callable);
    System.out.println(myName + ": Running task");
    System.out.flush();
    executorS.execute(futureTask); // Starte die Berechnung

    return futureTask;
  }
}

[Der Andere (Gast)]

Jay schrieb:
> Etwas moderner (ok, das Konzept stammt schon aus Anfang der 90er oder
> früher, aber Java hat es spät implementiert) ist es Futures zu
> verwenden.

Macht nur Sinn, wenn man mit Threads Berechnungen parallelsieren will 
und die Ergebnisse braucht.
Für einen Thread der unbestimmt lange als "Daemon Thread" neben dem 
Hauptprogramm läuft und erst mal unabhängig werkelt ist das Unsinn.

Ausserdem hab ich daruf oben schon hingewiesen

Der Andere schrieb:
> Dazu solltest du dir Thread Pools anschauen Package:
> java.util.concurrent

Aber der TO kann ja nicht mal eine Klasse von Thread ableiten und die 
dann starten. Also sind Future Callable und Threadpools für ihn soch so 
weit weg wie der Mond.

Ahnungsloser schrieb:
> Das funktioniert bei mir schon gleich garnicht..es müsste doch wenn dann
>>Failure_Msg_Thread failure_handling = new Failure_Msg_Thread
> lauten?!

Siehe meine Korrekur.
Aber auch hier: Grundlagen was ist Polymorphie
https://de.wikipedia.org/wiki/Objektorientierung#Polymorphie

[Ahnungsloser (Gast)]

Da wird doch mit Kanonen auf Spatzen geschossen.
Es muss doch auch mit meinem Code gehen.
Wenn ich ein Objekt von "Failure_Msg_Thread" erzeuge, läuft der Thread 
zwar, aber das Main-Programm hängt sich auf. (Warum auch immer..)

Immerhin hat der Thread bei der "falschen" Notation funktioniert:
>failure_handling = new Thread(new Failure_Msg_Thread
Er lässt sich nur nicht beenden.

Ich verstehe es nicht :(

[Jay (Gast)]

Der Andere schrieb:
> Macht nur Sinn, wenn man mit Threads Berechnungen parallelsieren will
> und die Ergebnisse braucht.

Was er ja wohl will (den Boolean den er haben will). Aber egal, alles 
nicht mein Problem.

[Der Andere (Gast)]

Jay schrieb:
> Was er ja wohl will (den Boolean den er haben will). Aber egal, alles
> nicht mein Problem.

Die boolean Variable ist zu Signalisierung dass der Thread sich beenden 
soll.
Dein Problem ist hier eher das verstehende Lesen :-)

Ahnungsloser schrieb:
> Ich verstehe es nicht :(

Dann backe erst mal kleinere Brötchen bis du Klassen und Objekte und 
deren Instanziierung verstanden hast.
Sorry, aber ich muss jetzt mal wieder was arbeiten.

[Jay (Gast)]

Der Andere schrieb:
> Dein Problem ist hier eher das verstehende Lesen :-)

Dein Problem ist, dass du ein Arsch bist.

> Sorry, aber ich muss jetzt mal wieder was arbeiten.

Ah, jetzt verschwinden, nachdem du alle Weggebissen hast. Sehr 
sympathisch.

[Ahnungsloser (Gast)]

>Dann backe erst mal kleinere Brötchen bis du Klassen und Objekte und
>deren Instanziierung verstanden hast.

Das habe ich. Sorry für meinen Fehler vorhin...

Sobald ich FailureMsgThread instanziiere und <OBJEKT>.run(); ausführe, 
läuft zwar der Thread bis zum St.Nimmerleinstag, aber das Main-Programm 
hängt sich auf.

Ich schicke jetzt nochmal meinen Code, in der Hoffnung, dass mir jemand 
hilft und mich nicht fertig macht, weil ich ja so ein dummer Anfänger 
bin.

Thread:

public class Failure_Msg_Thread implements Runnable 
{
  public boolean stopThread;
  private JLabel overvoltage;
  private JLabel overtemperature;
  
  Failure_Msg_Thread(JLabel overtemperature, JLabel overvoltage);
  {
    this.overvoltage = overvoltage;
    this.overtemperature = overtemperature;
    stopThread=false;
  }
  

  @Override
  public void run() 
  {
    
    while(stopThread != false)
    {
        try 
        {
            Thread.sleep(3000);               
        }        
        
        catch(InterruptedException ex) 
        {
            Thread.currentThread().interrupt();
        }
        
        String fault_detection = LeftRightMid.mid(DeviceInfo, 23,2);
        try        
        {
           if(fault_detection.equals("25")) {overtemperature.setOpaque(true); overtemperature.setBackground(Color.red);}
           if(fault_detection.equals("85")) {overvoltage.setOpaque(true); overvoltage.setBackground(Color.red);}
        }
          
        
        catch (UnknownHostException e1) 
        {
          JOptionPane.showMessageDialog(null,"Unknown host!", "Error", JOptionPane.PLAIN_MESSAGE);
          
          e1.printStackTrace();
        } 
        
        catch (IOException e1) 
        {
          //JOptionPane.showMessageDialog(null,"No connection!", "Error", JOptionPane.PLAIN_MESSAGE);

          e1.printStackTrace();
        }
    }
  }
}

(/c]




Hauptklasse:
[c]

public class ThreadTest extends JFrame implements ActionListener
{
  

  //////////// Konstruktor //////////
  ThreadTest()
  {
    .....
  }
  //////////////////////////////////
  
  
  Failure_Msg_Thread failure_handling = new Failure_Msg_Thread(lbl_Overtemp,lbl_Overvoltage);

    
  if (e.getSource() == btn_StartRC)
  {
      
       failure_handling.run();
         
  }
      
  if (e.getSource() == btn_StopRC)
  {
    /// Hier soll Thread gestoppt werden  
  }
}

Danke!

[foo (Gast)]

Ahnungsloser schrieb:
> private JLabel overvoltage;

Achso, es geht um Swing!
Das hättest du auch gleich sagen können.
http://www.javacreed.com/swing-worker-example/

[Ahnungsloser (Gast)]

SwingWorker? noch nie gehört.


Das Problem ist, dass der Thread einwandfrei funktioniert: Er lässt sich 
nur nicht schließen/beenden!!!!

[foo (Gast)]

Ahnungsloser schrieb:
> SwingWorker? noch nie gehört.

Dann ist es jetzt Zeit, sich damit anzufreunden, wenn du eh Swing 
machst.

> Das Problem ist, dass der Thread einwandfrei funktioniert: Er lässt sich
> nur nicht schließen/beenden!!!!

Nein, das Problem ist, dass du das Problem nicht kennst, du meinst eine 
Lösung (Thread, wobei, nichtmal das, du implementierst ja "Runnable") zu 
kennen.
Das tritt hier im Forum sehr oft auf, die Leute kommen mit Lösungen 
und nicht mit Problemen.
Dein Problem ist:
Du hast eine Swing-Anwendung und willst irgendwas abbrechbares im 
Hintergrund machen, das sporadisch deine Oberfläche aktualieren soll.
Die Lösung dazu:
SwingWorker

[Ahnungsloser (Gast)]

Ok..dann werde ich mich heute Abend entsprechend einlesen und bedanke 
mich schonmal für das Stichwort! :)

Ich melde mich, falls Probleme auftreten.

Grüße u. Danke!

[Der Andere (Gast)]

Ahnungsloser schrieb:
> Sobald ich FailureMsgThread instanziiere und <OBJEKT>.run(); ausführe,

In meinem oben angegebenen Link zum Tutorial wird dir erklärt warum du 
start() und nicht run() aufrufen sollst. run() läuft nämlich im 
Hauptthread und nicht in einem neuen, und da die run() Methode eben 
wartet bis sie ein zeichen zum Beenden kriegt, das sie aber nie kriegen 
kann weil das Programm ja jetzt nicht weiterlaufen kann, hängt das 
Programm.

Nochmal: Ohne Grundlagen hangelst du dich nur von einem Problem zum 
anderen.
Das ist doch wieder mal "programming by copy paste".



Jay schrieb:
> Der Andere schrieb:
>> Dein Problem ist hier eher das verstehende Lesen :-)
>
> Dein Problem ist, dass du ein Arsch bist.

Was du bist zeigst du ganz klar, Unfug schreiben, keine Argumente, dafür 
Beleidigungen.

Jay schrieb:
> Ah, jetzt verschwinden, nachdem du alle Weggebissen hast. Sehr
> sympathisch.

Im Gegensatz zu dir muss ich arbeiten und verdiene damit Geld. Der 
Wadenbeisser passt besser zu dir. Und ich habe wenigstens konkret 
geholfen statt 100 Zeilen viel zu komplexen und nicht zum Problem 
passenden Code einfach einem Anfänger vorzuwerfen.
Ob du selbst den Code verstehst oder nur irgendwo rauskopiert hast weist 
nur du (hoffentlich).

[Foobar (Gast)]

  if (e.getSource() == btn_StartRC)
  {
      
       new Thread(failure_handling).start(); // sonst wird kein Thread gestartet, sondern du führst nur die Run-Methode im aktuellen Thread aus!
         
  }
      
  if (e.getSource() == btn_StopRC)
  {
    /// Thread Bescheid geben, dass er stoppen soll.
    failure_handling.stopThread = true;
  }

[markus (Gast)]

Ahnungsloser schrieb:
> läuft zwar der Thread bis zum St.Nimmerleinstag
Ist kein Thread, heißt nur so.

> aber das Main-Programm
> hängt sich auf.
Tut es nicht. Es führt die run-Methode Deines Failure_Msg_Thread-Objekts 
aus.
Du erstellst gar keinen Thread und startest auch keinen.
Ein Runnable fängt nicht von selbst an, in einem eigenen Thread zu 
laufen, indem man seine run-Methode aufruft.

[Ahnungsloser (Gast)]

Also ich versuche es jetzt mal mit dem SwingWorker..Gruß

[Ahnungsloser (Gast)]

Gestern habe ich noch bis 1 Uhr diesen SwingWorker versucht zu nutzen.
Leider mit noch weniger Erfolg.

Ich nahm die alten Anweisungen der Klasse Failure_Msg_Thread und 
kopierte sie in die "execute()"-Methode.
Die "DoinBackground"-Methode funktionierte garnicht, bei der 
"execute"-Methode habe ich seither den Fehler:
"Cannot override the final method from Swingworker<Integer,Integer>"

Grundgerüst der ThreadKlasse sieht so aus:

public class Failure_Msg_Thread extends SwingWorker<Integer, Integer>
{
  
  public boolean stopThread;
  
  Failure_Msg_Thread()
  {

  }
  
  
  
  
  public void execute() throws Exception 
  {
    while(stopThread != true)
    {
      // Hier sollen die Anweisungen stehen        
            
    }    
  }


  @Override
  protected Integer doInBackground() throws Exception 
  {
    // TODO Auto-generated method stub
    return null;
  }

  
  
}

Im Hauptprogramm rufe ich das Ganze dann mit ".execute()" auf. 
Funktioniert wiegesagt ja nicht, da ein Fehler in der Threadklasse 
vorliegt, den ich nicht zu beheben weiß...

Wisst ihr weiter?

Danke.

[Ahnungsloser (Gast)]

Ok, habe es jetzt behoben, der Thread läuft bereits.
Jetzt gilt es ihn nur noch zu beenden!

Melde mich, ob es klappt! :)

[Mladen G. (Gast)]

Ist immer noch falsch..

public volatile boolean stopThread;


Waere auch besser einen Setter zu nutzen.

[Ahnungsloser (Gast)]

Nachtrag:

public class Failure_Msg_Thread extends SwingWorker<Integer, Integer>
{
  
  public boolean stopThread;
  
  Failure_Msg_Thread()
  {
      stopThread = false;
  }
  
  public void setStop()
  {
      stopThread = true;
  }
  
  
  @Override
  protected Void doInBackground() throws Exception 
  {
      while(stopThread != true)
      {
        // Hier steht der Code, der auch ausgeführt wird!              
      }   
  }

  
  
}

Nach meinem Dafürhalten sollte ja jetzt beim Ausführen von 
<OBJEKT>.setStop() das entsprechende Stop-Flag gesetzt werden, damit das 
Ding anhält und nicht mehr ewig weiterläuft.
TUT ES ABER WIEDER NICHT!

So rufe ich es auf:

if (e.getSource() == btn_Stop)
    {
    
      Failure_Msg_Thread.setStop();
                }

Bin jetzt wirklich mit meinem Latein am Ende und hoffe nun auf eure 
Hilfe!


Gruß

[foo (Gast)]

Ahnungsloser schrieb:
> Die "DoinBackground"-Methode funktionierte garnicht, bei der
> "execute"-Methode habe ich seither den Fehler:

Öhm, wie kommst du auf die Idee execute zu überschreiben? Das ist 
absolut nicht nötig.

Dein Hintergrundzeugs muss natürlich in doInBackground() laufen, die 
Methode heisst ja schon so...
Dieses ganze Gedöns mit dem boolean kannst dir auch sparen, du kannst 
den laufenden Worker jederzeit mit cancel() abbrechen (das steht auch in 
dem verlinkten Beispiel).
Deine JLabel versorgst du aus der Methode process (die du, vielleicht 
etwas ungewohnt, über publish aufrufst):

@Override
protected void process(List<String> chunks) {
    // Messages received from the doInBackground() (when invoking the publish() method)
}

Warum du jetzt mit SwingWorker<Integer, Integer> arbeitest und nicht mit 
SwingWorker<Void, Void> oder gar SwingWorker<BigDecimal, String> 
solltest du dir auch nochmal durch den Kopf gehen lassen.

[foo (Gast)]

Und weil du wahrscheinlich nicht von selber drauf kommst:

Nochmal, schmeiss diesen ganzen boolean-kram raus, getter, setter, 
variable, alles.
SwingWorker bietet dir isCancelled() an (die du bitte nicht selber 
implementierst).

In deiner doInBackground() steht dann also als erstes:

while(!isCancelled()){

[Ahnungsloser (Gast)]

Hi,

danke für deine Antwort, ich denke meine letzte Antwort hat sich mit 
deiner überschnitten.

Ich prüfe nun in meiner Endlosschleife in der Threadklasse folgendes:

protected Void doInBackground() throws Exception   
{ 
   while(!isCancelled())
   {
     Thread.sleep(3000);                ///// Polling-Intervall
       .....          
   }
}

Im Hauptprogramm mache ich folgendes:

Failure_Msg_Thread fmt = new Failure_Msg_Thread(....);

if (e.getSource() == btn_StopRC)
{  fmt.execute();   }

if (e.getSource() == btn_StopRC)
{    
   fmt.cancel(true);
}

Es wird jedenfalls NICHT beim Klick auf "Stop" der Thread beendet. Der 
läuft einfach weiter..

[Ahnungsloser (Gast)]

der eine Button muss "btn_StartRC" heißen...sch*** copy&paste.
In meinem Programm stimmt das schon.

[foo (Gast)]

So, ich hab jetzt mal auf die Schnelle ein lauffähiges Beispiel 
gebastelt (Das UI ist schnell in Netbeans geklickt..)

import java.util.Iterator;
import java.util.List;
import javax.swing.SwingWorker;

public class SwingWorkerTest extends javax.swing.JFrame {

    public SwingWorkerTest() {
        initComponents();
    }

    // <editor-fold defaultstate="collapsed" desc="Generated Code">                          
    private void initComponents() {

        javax.swing.JPanel southPanel = new javax.swing.JPanel();
        buttonStart = new javax.swing.JButton();
        buttonStop = new javax.swing.JButton();
        scroll = new javax.swing.JScrollPane();
        textArea = new javax.swing.JTextArea();

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

        southPanel.setLayout(new java.awt.BorderLayout());

        buttonStart.setText("start");
        buttonStart.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                buttonStartActionPerformed(evt);
            }
        });
        southPanel.add(buttonStart, java.awt.BorderLayout.WEST);

        buttonStop.setText("stop");
        buttonStop.setEnabled(false);
        buttonStop.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                buttonStopActionPerformed(evt);
            }
        });
        southPanel.add(buttonStop, java.awt.BorderLayout.LINE_END);

        getContentPane().add(southPanel, java.awt.BorderLayout.SOUTH);

        textArea.setColumns(20);
        textArea.setRows(5);
        scroll.setViewportView(textArea);

        getContentPane().add(scroll, java.awt.BorderLayout.CENTER);

        pack();
    }// </editor-fold>                        

    private void buttonStartActionPerformed(java.awt.event.ActionEvent evt) {                                            
        buttonStop.setEnabled(true);
        buttonStart.setEnabled(false);
        worker = new Worker();
        worker.execute();
    }                                           

    private void buttonStopActionPerformed(java.awt.event.ActionEvent evt) {                                           
        worker.cancel(true);
    }                                          

    private class Worker extends SwingWorker {

        @Override
        protected Object doInBackground() {
            int cnt = 0;
            while (!isCancelled()) {
                publish(Integer.toString(++cnt));
                try {
                    Thread.sleep(1000);    
                } catch (InterruptedException e) {
                    break;                 
                }
            }
            return "Stopped."; 
        }

        @Override
        protected void process(List display) {
            Iterator it = display.iterator();
            while (it.hasNext()) {
                textArea.append((String) it.next() + "\n");
                textArea.setCaretPosition(textArea.getText().length());
            }
        }

        @Override
        protected void done() {
            textArea.append("Stopped.");
            textArea.setCaretPosition(textArea.getText().length());
            buttonStart.setEnabled(true);
            buttonStop.setEnabled(false);
        }
    }

    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            @Override
            public void run() {
                new SwingWorkerTest().setVisible(true);
            }
        });
    }

    private SwingWorker worker;
    // Variables declaration - do not modify                     
    private javax.swing.JButton buttonStart;
    private javax.swing.JButton buttonStop;
    private javax.swing.JScrollPane scroll;
    private javax.swing.JTextArea textArea;
    // End of variables declaration                   
}

[Ahnungsloser (Gast)]

Danke für deine Mühe. Aber das löst leider auch nicht mein Problem, da 
ich keinerlei Unterschiede zwischen deinem Code zum Stoppen des 
SwingWorkers..:

  @Override
        protected Object doInBackground() {
            int cnt = 0;
            while (!isCancelled()) {
                publish(Integer.toString(++cnt));
                try {
                    Thread.sleep(1000);    
                } catch (InterruptedException e) {
                    break;                 
                }
            }
            return "Stopped."; 
        }

..und meinem erkenne. Wiegesagt, der Swingworker läuft einwandfrei, aber 
er lässt sich (wie auch der Thread) einfach nicht stoppen/beenden:

@Override
protected Void doInBackground() throws Exception 
{        
  while(!isCancelled())
        {    
            Thread.sleep(1000);    
             ... Anweisungen...
        } return; }

Liegt es denn eventuell an meinem "throws Exception" beim Methodenkopf?

protected Void doInBackground() throws Exception

Danke

[Ahnungsloser (Gast)]

Kann es daran liegen, dass ich in "DoInBackground" mit Anweisungen 
arbeiten, die exceptions benötigen?
(Öffne darin einen Socket u. diverse Input/Outputstreams)?

[Ahnungsloser (Gast)]

Fehler gefunden.

Das Problem lag daran, dass die Instanziierung von "Failure_Msg_Thread" 
außerhalb der beiden IF-Anweisungen im Hauptprogramm erfolgte.

So lässt er sich starten, aber NICHT beenden:

public void actionPerformed(ActionEvent e) 
{  
     fmt = new Failure_Msg_Thread(..);

     if(e.getSource() == btn_start)
     {
      fmt.execute();  
      ...
     }

     if(e.getSource() == btn_stop)
     {
      fmt.cancel(true);   // wirkungslos!  
      ...
     }
}

So aber lässt er sich starten und stoppen:

public void actionPerformed(ActionEvent e) 
{  
     

     if(e.getSource() == btn_start)
     {
       fmt = new Failure_Msg_Thread(..);
       fmt.execute();  
      ...
     }

     if(e.getSource() == btn_stop)
     {
       fmt.cancel(true);   // wirkungslos!  
      ...
     }
}

Das verstehe ich überhaupt nicht. Aber gut..läuft jetzt.

Gruß

[foo (Gast)]

Ahnungsloser schrieb:
> Das verstehe ich überhaupt nicht.

Ich überlass dir das mal als Fleissaufgabe.

> Aber gut..läuft jetzt.

Nur wie halt.
Dein Exceptionhandling ist defacto nicht vorhanden.

Einfach

protected Void doInBackground() throws Exception

hinzurotzen sorgt zwar dafür, dass dein Code anstandslos compiled, aber 
eigentlich macht man das anders.
Schau dass du das in der Schleife sauber abfängst mit multicatch (ein 
try, viele catches) und entsprechend passende Meldungen ausgibst und die 
Schleife sauber verlässt.

[Ahnungsloser (Gast)]

>Ich überlass dir das mal als Fleissaufgabe.

Man kann doch in einer Methode ein Objekt erzeugen.
Das Verhalten müsste doch eigentlich genau andersrum sein, dass die 
If-Anweisung von einer anderen If-Anweisung gekapselt ist und ich in der 
zweiten If nichtmal das Objekt der ersten sehen dürfte?!

[Foobar (Gast)]

Klar und du hast jedesmal ein neues Objekt erzeugt und dieses dann 
angehalten.... aber nicht den Thread der bei einem früheren Aufruf der 
ActionPerformed-Methode erzeugt wurde....

Du solltest mal an den Grundlagen arbeiten..

[Ahnungsloser (Gast)]

Ahh, das leuchtet ein! Danke!

[foo (Gast)]

Wenn du dann das mit den Exceptions (incl. aussagekräftigen 
Fehlermeldungen und sauberen exits) ausprogrammiert hast, kannst ja auch 
mal noch so eine Verriegelung wie in meinem Beispiel einbaun.
Weil: http://imgur.com/vRF9b47

[Der Andere (Gast)]

Foobar schrieb:
> Du solltest mal an den Grundlagen arbeiten..

Warum nur kommt mir der Satz bekannt vor...

[Läubi .. (laeubi)]

Ahnungsloser schrieb:
> Liegt es denn eventuell an ...

Das liegt daran das du erst mal ein paar Grundlagen dir aneignen und 
VERSTEHEN solltest! Programmieren ist doch keine Quizshow wo man sich 
munter von Frage zu frage "rät" und im Zweifle den Foren-Joker befragt.

Ahnungsloser schrieb:
> Bin jetzt wirklich mit meinem Latein am Ende

Latein (oder eine andere Sprache, gilt auch für Programmiersprachen) 
lernt man auch nicht dadurch das man sich aus irgendwelchen Büchern 
Satzfetzen zusammenkopiert....

[Markus (Gast)]

Läubi .. schrieb:
> Programmieren ist doch keine Quizshow wo man sich
> munter von Frage zu frage "rät" und im Zweifle den Foren-Joker befragt.
Jetzt weiß er aber wenigsten, was Backtracking ist, aber nicht, daß man 
das nicht für die Entwicklung verwendet.

[27hdec (Gast)]

Einfach return;