9.5 Die Zustände eines Threads 

Bei einem Thread-Exemplar können wir einige Zustände feststellen: Noch nicht erzeugt, laufend (vom Scheduler berücksichtigt), nicht laufend (vom Scheduler nicht berücksichtigt), wartend und beendet. Wie das Leben eines Thread-Objekts beginnt, haben wir schon kennen gelernt – es muss nur mit new erzeugt werden, ist aber noch nicht im Zustand ausführend. Durch start() gelangt der Thread in den Zustand »ausführbar« beziehungsweise »laufend«. Der Zustand kann sich ändern, wenn ein anderer Thread in einem Einprozessorsystem zur Ausführung gelangt und dann dem aktuellen Thread den Prozessor entzieht. Anschließend geht der vorherige Thread für einen kurzen Moment in den wartenden Zustand. Dieser wird auch erreicht, wenn wir mittels spezieller Synchronisationstechniken in einem Wartezustand verweilen. Nachdem die Aktivität des Thread-Objekts beendet wurde, kann es nicht mehr aktiviert werden und es ist tot, also beendet.

9.5.1 Das Ende eines Threads 

Es gibt Threads, die dauernd laufen, weil sie zum Beispiel Serverfunktionen implementieren. Andere Threads führen einmalig eine Operation aus und sind danach beendet. Allgemein ist ein Thread beendet, wenn eine der folgenden Bedingungen zutrifft:

Die run()-Methode wurde ohne Fehler beendet. Wenn wir eine Endlosschleife programmieren, würde diese dann potenziell einen nie endenden Thread bilden.

In der run()-Methode tritt eine Exception auf, die die Methode beendet.

Der Thread wurde von außen abgebrochen. Dazu dient die prinzipbedingt problematische Methode stop(), von deren Verwendung abgeraten wird und die auch veraltet ist.

9.5.2 Einen Thread höflich mit Interrupt beenden 

Der Thread ist in der Regel zu Ende, wenn die run()-Methode ordentlich bis zum Ende ausgeführt wurde. Enthält eine run()-Methode jedoch eine Endlosschleife – wie etwa bei einem Server, der auf eingehende Anfragen wartet –, so muss der Thread von außen zur Kapitulation gezwungen werden. Die nahe liegende Möglichkeit, mit der Thread-Methode stop() einen Thread abzuwürgen, wollen wir an anderer Stelle diskutieren.

Wenn wir schon nicht von außen den Thread beenden wollen, dann können wir ihn bitten, dass er seine Arbeit aufgibt. Periodisch müsste er dann nur überprüfen, ob von außen jemand den Abbruchswunsch geäußert hat. Dies könnte etwa durch eine Objektvariable stopp geschehen, die beim Initialisieren den Startwert false bekäme. Periodisch würden wir nun in run() testen, ob stopp uns zur Aufgabe zwingt oder wir weitermachen können. Von außen kann der Thread durch die einfache Zuweisung stopp=true angehalten werden. Diese Lösung ist einfach und effektiv. Sie funktioniert jedoch nur dann gut, wenn stopp regelmäßig abgefragt wird. Leider verbraucht die dauernde Fragerei auch Laufzeit.

Die Methoden interrupt() und isInterrupted()

Natürlich haben die Java-Entwickler an eine Lösung schon gedacht und drei Methoden implementiert, mit denen sich eine Unterbrechung ankündigen und abfragen lässt. Mit der Methode interrupt() wird in einem Thread-Objekt von außen ein internes Flag gesetzt, welches dann in der run()-Methode durch isInterrupted() periodisch abgefragt werden kann.

Listing 9.7   ThreadusInterruptus.java

class ThreadusInterruptus extends Thread
{
  public void run()
  {
    System.out.println( "Der Anfang" );

     while ( true )
    {
      if ( isInterrupted() )
        break;

      System.out.println( "Hurra" );

      try {
        Thread.sleep( 500 );
      }
      catch ( InterruptedException e ) {
         interrupt();

      }
    }

    System.out.println( "Das Ende" );
  }

  public static void main( String args[] )
  {
    ThreadusInterruptus t = new ThreadusInterruptus();

    t.start();
    try {
      Thread.sleep( 2000 );
    } catch ( InterruptedException e ) { }

    t.interrupt();
  }
}

Die run()-Methode im Thread ist so implementiert, dass die Endlosschleife genau dann verlassen wird, wenn isInterrupted() den Wert true ergibt, also von außen die interrupt()-Methode für dieses Thread-Exemplar aufgerufen wurde. Genau dies geschieht in der main()-Methode. Auf den ersten Blick ist das Programm leicht verständlich, doch vermutlich erzeugt das interrupt() im Catch-Block die Aufmerksamkeit. Stünde diese Zeile dort nicht, würde das Programm aller Wahrscheinlichkeit nach nicht funktionieren. Das Geheimnis ist folgendes: Wenn die Ausgabe nur alle halbe Sekunde stattfindet, dann befindet sich der Thread fast die gesamte Zeit in der Schlaf-Methode sleep(). Also wird vermutlich der interrupt() den Thread gerade beim Schlafen stören. Genau dann wird sleep() durch InterruptedException unterbrochen und der catch()-Behandler fängt die Ausnahme ein. Jetzt passiert aber etwas Unerwartetes: Durch die Unterbrechung wird das interne Flag zurückgesetzt, sodass isInterrupted() meint, die Unterbrechung habe gar nicht stattgefunden. Daher muss interrupt() erneut aufgerufen werden, da das Abbruch-Flag neu gesetzt werden muss, und isInterrupted() das Ende bestimmen kann. Wenn wir mit der isInterrupted()-Methode arbeiten, dann müssen wir beachten, dass auch die Methoden join() und wait() durch die InterruptedException das Flag löschen.

Zusammenfassung: interrupted(), isInterrupted() und interrupt()

Die Methodennamen sind sehr verwirrend gewählt, sodass wir die Aufgaben noch einmal zusammenfassen wollen. Die Objektmethode interrupt() setzt in einem (anderen) Thread-Objekt ein Flag, dass es einen Antrag gab, den Thread zu beenden. Dieses Flag lässt sich mit der Objektmethode isInterrupted() abfragen. In der Regel wird dies innerhalb einer Schleife geschehen, die darüber bestimmt, ob die Aktivität des Threads fortgesetzt werden soll. Die Klassenmethode interrupted() ist dagegen mehr als eine Anfragemethode (daher fehlt auch der Präfix is-). Sie testet zwar das entsprechende Flag des aktuell laufenden Threads, wie currentThread().isInterrupted(), aber modifiziert ihn auch, sodass er danach gelöscht ist. Zwei aufeinander folgende Aufrufe von interrupted() führen daher zu einem false; es sei denn, in der Zwischenzeit kam eine weitere Unterbrechung.

9.5.3 Der stop() von außen 

Wenn ein Thread nicht auf interrupt() hört, dann muss zum Abbruch die veraltete Methode stop() eingesetzt werden. Doch deprecated gibt uns schon einen guten Hinweis, dass wir dies besser nicht machen sollten. (Leider gibt es hier, im Gegensatz zu den meisten anderen veralteten Methoden, keinen einfachen, empfohlenen Ersatz.) Überschreiben können wir stop() auch nicht, da es final ist. Wenn wir einen Thread von außen beenden, geben wir ihm keine Chance mehr, seinen Zustand konsistent zu verlassen. Zudem kann die Unterbrechung an beliebiger Stelle erfolgen, sodass angeforderte Ressourcen frei in der Luft hängen können.

class java.lang.Thread

implements Runnable

void checkAccess() Findet heraus, ob wir die Möglichkeit haben, den Zustand oder die Eigenschaften des Thread-Objekts von außen zu ändern. checkAccess() der Klasse Thread ruft die check Access()-Methode vom Security-Manager auf; möglicherweise bekommen wir eine SecurityException.

void stop() Wurde der Thread gar nicht gestartet, kehrt die Funktion sofort zurück. Andernfalls wird über checkAccess() geprüft, ob wir überhaupt das Recht haben, den Thread abzuwürgen. Dann wird der Thread beendet, egal was er gerade gemacht hat und das Letzte, was der Thread jetzt noch kann, ist sein Testament in Form eines ThreadDeath-Objekts als Exception anzuzeigen.

9.5.4 Das ThreadDeath-Objekt 

So unmöglich ist das Reagieren auf ein stop() auch nicht. Immer dann, wenn ein Thread mit stop() zu Ende kommen soll, löst die JVM eine ThreadDeath-Ausnahme aus, die letztendlich den Thread beendet. ThreadDeath ist eine Unterklasse von Error. Error ist wiederum von Throwable abgeleitet, sodass ThreadDeath mit einem try/catch-Block abgefangen werden kann. Die Java-Entwickler haben ThreadDeath nicht zu einer Unterklasse von Exception gemacht, weil sie nicht wollten, dass ThreadDeath bei einer allgemeinen Exception-Behandlung über catch(Exception e) abgefangen wird.

Wenn wir ThreadDeath auffangen, dann können wir noch auf den Tod reagieren und Aufräumarbeiten erlauben. Wir sollten aber nicht vergessen, anschließend das aufgefangene ThreadDeath-Objekt wieder auszulösen, denn sonst wird der Thread nicht beendet.

Listing 9.8   ThreadWiederbelebung.java

class ThreadWiederbelebung
{
  public static void main( String args[] )
  {
    class RunEndlos implements Runnable
    {
      public void run()
      {
        try
        {
          while ( true )
            ;
        }
        catch ( ThreadDeath td )

        {
          System.out.println( "Da haben wir aber noch mal "+
                              "Glück gehabt" );
          throw td;
        }
      }
    }

    Thread t = new Thread( new RunEndlos() );
    t.start();
    t.stop();
  }
}

ThreadDeath kann auch verwendet werden, um das aktuell laufende Programm zu beenden (aber System.exit() ist weniger extravagant).

throw new ThreadDeath();

9.5.5 Auf das Ende warten mit join() 

Aus diesen Eigenschaften leitet sich ab, dass ein Thread keine Ergebnisse wie eine Funktion nach außen geben kann. Die run()-Methode hat den Ergebnistyp void, und da ein nebenläufiger Thread asynchron arbeitet, wissen wir noch nicht einmal, wann wir das Ergebnis erwarten können. Die Übertragung von Werten ist jedoch kein Problem. Hier können Klassenvariablen und auch Objektvariablen helfen, denn über sie können wir kommunizieren. Jetzt fehlt nur noch, dass wir auf das Ende der Aktivität eines Threads warten können. Das geht mit der Methode join().

Listing 9.9   JoinTheThread.java

class JoinTheThread
{
  static class JoinerThread extends Thread
  {
    public int result;

    public void run()
    {
      result = 1;
    }
  }

  public static void main( String args[] ) throws Exception
  {
    JoinerThread t = new JoinerThread();
    t.start();

//    t.join();



    System.out.println( t.result );
  }
}

Ohne den Aufruf von join() wird als Ergebnis 0 ausgegeben, denn das Starten des Threads kostet etwas Zeit. In dieser Zeit aber geben wir die nicht initialisierte Klassenvariable aus. Nehmen wir join() hinein, wird die run()-Methode zu Ende ausgeführt und der Thread setzt die Variable result auf 1. Das sehen wir dann auf dem Bildschirm.

class java.lang.Thread

implements Runnable

final void join() throws InterruptedException Der aktuell ausgeführte Thread wartet auf den Thread, für den die Methode aufgerufen wird, bis dieser beendet ist.

final synchronized void join( long millis ) throws InterruptedException Wie join(), doch wartet diese Variante höchstens millis Millisekunden. Wurde der Thread bis dahin nicht vollständig beendet, fährt das Programm fort. Auf diese Weise kann versucht werden, innerhalb einer bestimmten Zeitspanne auf den Thread zu warten, sonst aber weiterzumachen. Ist millis gleich 0, so hat dies die gleiche Wirkung wie join().

final synchronized void join ( long millis, int nanos ) throws InterruptedException Wie join(long), jedoch mit potenziell genauerer Angabe der maximalen Wartezeit.

Warten auf den Langsamsten

Große Probleme können in mehrere Teile zerlegt werden und jedes Teilproblem kann dann von einem Thread gelöst werden. Das ist insbesondere bei Mehrprozessorsystemen eine lohnenswerte Investition. Zum Schluss müssen wir nur noch darauf warten, dass die Threads zum Ende gekommen sind und das Ergebnis einsammeln. Dazu eignet sich join() gut.

void go() throws Exception
{
  Thread a = new A();
  Thread b = new B();

  a.start();
  b.start();
  a.join();
  b.join();
}

Es ist unerheblich, wessen join() wir zuerst aufrufen, da wir sowieso auf den langsamsten Thread warten müssen. Wenn ein Thread schon beendet ist, dann kehrt join() sofort zurück.

Eine andere Lösung für zusammenlaufende Threads ist, diese in einer Thread-Gruppe zusammenzufassen. Dann können sie zusammen behandelt werden, sodass nur das Ende der Thread-Gruppe beobachtet wird.