Wir haben uns bereits in der letzten Ausgabe dieser Kolumne (siehe / KRE7 /) einen Überblick über Neuerungen im JDK 5.0 angesehen, die für die Multithread-Programmierung zur Verfügung stehen.  Darunter sind auch Abstraktionen, die das Ausführen von Tätigkeiten in Threads unterstützen.  Am spannendsten ist dabei sicher der Threadpool, mit dessen Hilfe sich Tätigkeiten auf bereitstehende Threads verteilen und sogar ggf. in einer Taskqueue speichern lassen.  Der Threadpool verwendet dabei aber nicht nur das allseits bekannte Runnable zur Beschreibung einer asynchron ausführbaren Tätigkeit, sondern arbeitet auch mit den in Java 5.0 neuen Abstraktionen Callable und Future.  In diesem Beitrag sehen wir uns, zur Vorbereitung auf den nächsten Beitrag über Threadpools, die Interfaces Callable und Future an.
 

Ausführen von Threads

Entsprechend der UML sind die Namen von Interfaces kursiv. Genauso wird bei der Vererbung zwischen extends-Beziehungen (Pfeil mit durchgezogener Linie) und implements-Beziehungen (Pfeil mit gestrichelter Linie) unterschieden.

Das Diagramm ist relativ dicht gedrängt. Damit wird deutlich, wie umfangreich das Thema nun geworden ist. Bisher gab es an dieser Stelle ja nur das Interface Runnable. Alle anderen Abstraktionen sind mit dem JDK 5.0 neu dazugekommen. Eine weitere Neuerung des JDK 5.0, nämlich die Generics, werden bereits bei der Definition der neuen Abstraktionen genutzt. Future<V> ist zum Beispiel keine einfaches Interface, sondern ein generisches Interface mit einem Typparameter V.

Beginnen wir die Diskussion der neuen Abstraktionen mit den beiden neuen zentralen Interfaces Callable<V> und Future<V>.
 

Callable<V>

Callable<V> ist ein Interface, das parallel zum bereits seit JDK 1.0 existierenden Runnable eingeführt wurde. Beide Interfaces erlauben es, eine definierte Funktionalität asynchron ausführen zu lassen. Wie wohl allgemein bekannt ist, implementiert man dazu beim Runnable die Methode:

  public void run();

Die in run() implementierte Funktionalität kann dann asynchron in einem Thread ausgeführt werden. Beim einem Callable<V> ist es ganz ähnlich.  Es wird die folgende Methode implementiert:

  public V call() throws Exception;

Dabei ist der Returntype V der Methode call() der Typparameter des generischen Interfaces Callable<V>.   Mit diesem Typparameter ist es möglich,  von einer asynchronen Funktionalität, die in call() implementiert wurde, ein Ergebnis eines beliebigen, aber zur Compilezeit festen, Referenztyps zurückzubekommen. Falls auf Grund eines Fehlers kein Ergebnis ermittelt werden kann, ist es möglich, eine Exception zu werfen. Das heißt, Callable<V> erlaubt es nun explizit, ein Ergebnis bzw. einen Fehler von einer asynchron ausgeführten Tätigkeit zu bekommen. Mit Runnable war das so nicht direkt möglich.

Hier ist ein Beispiel für die Implementierung eines Callable, das die Anzahl der Millisekunden zurückliefert, die benötigt werden, um tausendmal "Hello World!" auszudrucken.

public class MyCallable implements Callable<Long> {
   public Long call()  {
      long t = System.currentTimeMillis();

      for (int I=0; I<1000; i++)
         System.out.println("Hello World!");

      return ( System.currentTimeMillis() – t);
   }
}

Ein Problem ist jetzt natürlich:  wie kann man ein Callable als eigenen Thread starten?  Die Schnittstelle der Klasse Thread hat sich mit dem JDK 5.0 nicht so geändert, dass jetzt alternativ ein Thread mit einem Callable gestartet werden kann. Hier wird weiterhin ein Runnable erwartet.  Es wäre genau betrachtet auch gar nicht sinnvoll gewesen, einem Thread ein Callable statt einem Runnable zu geben. Man hätte dann noch einen Mechanismus benötigt, um Ergebnisse oder Fehler des asynchron in einem eigenen Thread ablaufenden Callables zu ermitteln.

Nachfolgend wollen wir uns den Adapter ansehen, der aus einem Callable<V> ein Runnable macht, das man einem Thread übergeben und starten kann. Aber vorher sehen wir uns erst einmal das Future-Pattern an.  Die Adapterklasse FutureTask ist nämlich nicht nur ein Adapter, sondern bietet auch Unterstützung beim Abholen des Resultats eines Callable<V> - und darum geht es genau beim Future-Pattern.

Abbildung 2 zeigt die alle Klassen und Interfaces, die im Zusammenhang mit Runnable und Callable relevant sind.

Future<V>

• Callback
• Future-Pattern

Wie funktioniert nun das Future-Pattern, dem eigentlich unsere Hauptaufmerksamkeit gilt? Hier hat man eine explizite Abstraktion, das Future, welche die Synchronisation zwischen den Threads sowie die Ergebnisübergabe übernimmt. Im generischen Interface Future<V> des JDK 5.0 stehen dafür folgende Methoden zur Verfügung:

V get() throws InterruptedException, ExecutionException

• Wartet, bis die asynchrone Tätigkeit abgeschlossen ist, und gibt dann ihr Ergebnis zurück. Dabei ist V der Typparameter des generischen Interface Future<V>. Das heißt, es wird ein Ergebnisse vom einem beliebigen Referenztypen zurückgeliefert. Falls die Tätigkeit mit interrupt() abgebrochen wurde, wird die InterruptedException geworfen. Falls die Ausführung der Tätigkeit mit einer Exception abgebrochen wurde, wird die ExecutionException geworfen. Sie enthält die Orginal-Exception, die zum Abbruch geführt hat.

• Wartet die mit timeout und granularity definierte Zeitspanne ab, ob die asynchrone Tätigkeit beendet wird. Wenn ja, wird das Ergebnis zurückgeliefert. Wenn nein, wird die TimeoutException geworfen. Für die anderen Exception gilt das oben Gesagte.

• Gibt true zurück, falls die asynchrone Tätigkeit abgeschlossen ist.

• Gibt true zurück, falls die asynchrone Tätigkeit abgebrochen wurde, ehe sie abgeschlossen werden konnte.

• Unternimmt den Versuch, die Ausführung der asynchronen Tätigkeit zu unterbrechen.  Dieser Versuch schlägt natürlich fehl, wenn die Tätigkeit bereits abgeschlossen ist oder vorher schon abgebrochen wurde.  Wenn das Abbrechen möglich ist und die Tätigkeit noch nicht begonnen hat, dann wird die Tätigkeit gar nicht erst gestartet. Wenn die Tätigkeit schon läuft, dann wird abhängig vom Parameter mayInterruptIfRunning entschieden, ob das Abbrechen versucht wird.  Versucht wird das Abbrechen über den Aufruf von interrupt() auf dem ausführenden Thread.  Das heißt, ob sich die Tätigkeit tatsächlich abbrechen läßt, hängt davon ab, ob die Tätigkeit auf den Interrupt-Status des ausführenden Threads reagiert.  (Wie das mit dem Interrupt funktioniert, haben wir in / KRE6 / beschrieben.)  Wenn sich die Tätigkeit nicht abbrechen ließ, dann wird false zurückgegeben, sonst true.

Zum Interface Future<V> gibt eine Klasse in der Multithread-Support-Erweiterung des JDK 5.0, nämlich die FutureTask<V>, die die Funktionalität des Future Interfaces implementiert.

FutureTask<V>

Konstruieren läßt sich eine FutureTask<V> entweder mit einem Callable<V>, dessen Ergebnis sie beim Future<V>.get() zurückliefert, oder mit einem Runnable und einem vordefinierten Ergebniswert beliebigen Referenztyps, welcher beim Future<T>.get() zurückliefert wird.

FutureTask(Callable<V> callable)
FutureTask(Runnable runnable, V result)

Bekanntlich erzeugt ein Runnable gar kein Ergebnis, die FutureTask hat aber eine get() Methode, die ein Ergebnis zurückliefert.  Damit die FutureTask später beim Abholen des „Ergebnisses“ etwas abliefern kann, muß bei der Konstruktion dieses „Ergebnis“ bereits mitgegeben werden.  Dieser Wert, den man bei der Konstruktion der FutureTask zu dem Runnable dazugibt, ist sozusagen ein Dummy-Ergebnis. Wenn das durchgeschleuste Objekt gar nicht gebraucht wird, was häufig vorkommt, dann übergibt man üblicherweise Boolean.TRUE als Dummy.

Mit der Klasse FutureTask<V> lassen sich also Runnables und Callable<V>s in Runnables verpacken und als asynchrone Tätigkeiten starten, indem sie dem Konstruktor von Thread übergeben werden und der Thread danach gestartet wird. Man kann auf die Beendigung der Tätigkeit, mit oder ohne Ergebnis, warten. Das macht man über das Interface Future<V>.  Die asynchronen Tätigkeiten  lassen sich vorzeitig beenden, ebenfalls über das Interface Future<V>.  Insgesamt gesehen ist die FutureTask die zentrale Abstraktion, die das Ausführen (oder Abbrechen) einer asynchronen Tätigkeiten und das Entgegennehmen des resultierenden Ergebnisses (oder Fehlers) unterstützt.

Auch unter einem anderen Gesichtspunkt ist FutureTask<V> eine wichtige Klasse. Sie ist der Adapter, der aus einem Callable<V> ein Runnable macht. Das neu eingeführt Interface Callable<V> hat zwar gegenüber dem Runnable den Vorteil, dass jetzt auch ein Ergebnis bzw. eine Exception von einer asynchronen Tätigkeit zurückgeliefert werden kann, aber fast überall wird weiterhin ein Runnable und kein Callable<V> als Parameter erwartet. Zum Beispiel gibt es keinen neuen Konstruktor für Thread, der es erlauben würde, einen Thread mit einem Callable<V> zu konstruieren. In solchen Fällen benutzt man die FutureTask<V> als Adapter. Schauen wir uns dazu ein Beispiel an. Das folgende Callable<Integer> ist ein primitiver Benchmark, der zählt, wie häufig „Hello World!“ innerhalb von 1 sec ausdruckt werden kann, und liefert diese Anzahl als Ergebnis zurück.

public class HelloWorldCount implements Callable<Integer> {
  public Integer call() throws InterruptedException {
    long end = new Date().getTime() + 1000;

    int i;
    for (i = 0; new Date().getTime() < end; i++ ) {
      System.out.println("HelloWorld! ");
      if (Thread.interrupted())
        throw new InterruptedException();
    }
    return new Integer(i);
  }

  static public void main(String[] argv) {
    FutureTask<Integer> t = new FutureTask<Integer>(new HelloWorldCount()); // 1

    new Thread(t).start(); // 2

    try {
      System.out.println("Die Anzahl war: " + t.get());
    } catch (ExecutionException e) {
      Throwable th = e.getCause();
      if (th == null)
         System.out.println("HelloWorldCount wurde aus unbekannten Gründen abgebrochen. ");
      else if (th instanceof InterruptedException)
        System.out.println("HelloWorldCount wurde abgebrochen. ");
      else
        System.out.println("HelloWorldCount wurde mit folgendem Fehler: " + th + " abgebrochen. ");
    } catch (InterruptedException e) {
        System.out.println("HelloWorldCount wurde abgebrochen. ");
    }
  }
}

In der main-Methode wird nun unser HelloWorldCount (welches ein Callable<Integer> ist) mit Hilfe einer FutureTask<Integer> in ein Runnable adaptiert (Zeile 1) und in einem eigenen Thread als asynchrone Tätigkeit gestartet (Zeile 2). Der Rest der Methode besteht nur noch aus der Auswertung des Ergebnisses bzw. der Fehlers.

Das Beispiel zeigt u.a., wie man Exceptions, die von einer asynchronen Tätigkeit ausgelöst werden, lokal über das Future fangen und behandeln kann.  Das ist einer der Vorzüge der Callables.  Wenn man mit Runnables arbeitet, dann können diese Runnables ohnehin keine Checked Exceptions werfen, aber sie könnten noch immer Runtime Exceptions (oder Errors) auslösen.  Wenn ein Runnable so etwas tut, dann kann es passieren, dass der Thread mit einer Runtime Exception abbricht, ohne dass diese Ausnahmesituation irgendwo behandelt würde.  Was macht man dann?
 

Behandlung von ungefangenen Exceptions im Zusammenhang mit Threads

• Die statische Methode setDefaultUncaughtExceptionHandler() erlaubt es, einen globalen Handler vom Typ Thread.UncaughtExceptionHandler einzuhängen. Dieser Handler wird im Bedarfsfall für alle Threads genutzt.
• Mit der Instanzmethode setUncaughtExceptionHandler() hängt man einen Handler vom Typ Thread.UncaughtExceptionHandler für den Thread ein, auf dem die Methode aufgerufen wird.

• lokaler Handler (falls vorhanden)
• globaler Handler (falls vorhanden)
• ThreadGroup.uncaughtException() (immer vorhanden).

Hier ist ein Beispiel, in dem ein Uncaught-Exception-Handler für einen einzelnen Thread eingehängt wird:

class SomeRunnable implements Runnable {
  public void run() {
     …
     throw new SomeRuntimeException();
  }
}
class Test {
  private static void test1() {
     Thread th;
     Thread.UncaughtExceptionHandler eh = new Thread.UncaughtExceptionHandler() {
       public void uncaughtException(Thread t, Throwable e) {
         e.printStackTrace();
         … eigentliche Fehlerbehandlung …
       }
     };
     th = new Thread(new SomeRunnable ());
     th.setUncaughtExceptionHandler(eh);
     th.start();
  }
}

Eine solche Lösung  über einen Uncaught-Exception-Handler ist recht grobgranular.  Sie gilt entweder für einen Thread, wie im Beispiel gezeigt, oder für eine Gruppe von Threads oder alle Threads.  Man muß für das Einhängen eines Uncaught-Exception-Handlerist immer Zugriff auf den oder die Threads haben, die eine Tätigkeit ausführen. Wenn ein Thread mehrere Tätigkeiten ausführt, wie das zum Beispiel bei einem Threadpool der Fall ist, dann möchte man u.U. pro Tätigkeit eine gesonderte Fehlerbehandlung durchführen.  Das läßt sich mit einem Uncaught-Exception-Handler nicht erreichen.  Mit einem Future hingegen ist es problemlos möglich, die Runtime Exception (oder den Error) von einem Runnable ganz lokal abzuholen und zu behandeln.  Dazu muß man das Runnable in eine FutureTask verpacken; dann kann über Future.get() die Runtime Exception (oder der Error) genau dieses einen Runnables gefangen werden.  Das nachfolgende Beispiel skizziert eine solche Lösung:

class SomeRunnable implements Runnable {
  public void run() {
     …
     throw new SomeRuntimeException();
  }
}
class Test {
  private static void test() {
     Thread th;
     FutureTask<Void> f = new FutureTask<Void>(new SomeRunnable(), null);
     th = new Thread(f);
     th.start();
     try {
       f.get();
     } catch (Throwable e)  {
       e.printStackTrace();
       … eigentliche Fehlerbehandlung …
     }
  }
}

Die Lösung über das Future ist im allgemeinen die elegantere Lösung, weil sie lokal funktioniert, statt die Verantwortlichkeiten über verschiedene Teile des Programms zu verteilen.  Bei der Lösung über einen Uncaught-Exception-Handler muß man sich in die Erzeugung bzw. Konfiguration des ausführenden Threads einhängen, um etwaige Runtime Exceptions (oder Errors) zu behandeln. Das ist nicht immer möglich.  Im nächsten Artikel werden wir sehen, daß man Tätigkeiten auch einem Threadpool zur Ausführung übergeben kann.  Dann hat lediglich der Threadpool Zugriff auf die ausführenden Threads und der Benutzer sieht gar nicht, welcher Thread die betreffende Tätigkeit ausführt.  Damit hat der Benutzer auch gar keine Chance, zur Fehlerbehandlung einen Uncaught-Exception-Handler in den ausführenden Thread einzuhängen.  Dann bleibt nur der Weg, die Fehlerbehandlung an der einzelnen Tätigkeit aufzuhängen. Das ist auch sonst, unabhängig von der Verwendung eine Thread-Pools, sinnvoll, weil es meistens sowieso einen Programmteil gibt, der sich um die Beendigung und das Ergebnis der Tätigkeit kümmert.  Dieser Programmteil kann sich dann auch um das Scheitern der Tätigkeit per Runtime Exception (oder Error) kümmern.
 

Zusammenfassung

Literaturverweise

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Concurrent Java - Java Multithread Programming 4 day seminar ( open enrollment and on-site)