ExecutorService unter Java nutzen

Wenn unter Java die Ausführung von Quelltext parallelisiert werden soll, so können hierfür Threads genutzt werden:

Thread thread = new Thread(new TestRunnable());
thread.start();

In diesem Beispiel wird für eine auszuführende Aufgabe ein Thread erstellt und dieser anschließend gestartet. Nun kann es Fälle geben, in welchem mehrere Threads die gleiche Aufgabe ausführen sollen, allerdings nicht unbedingt die entsprechende Anzahl von Threads angelegt werden soll. Für eine solche Aufgabe eignet sich ein ExecutorService. Im ersten Schritt sollte ein Runnable definiert werden. In diesem Interface wird eine run-Methode definiert, die den auszuführenden Quellcode enthält:

public static class TestRunnable implements Runnable {

    @Override
    public void run() {
        // Do something
    }
}

Nun kann der ExecutorService angelegt werden und mit einem Threadpool ausgestattet werden. Anschließend werden die neuen Instanzen des Runnable, mittels der execute-Methode, an den ExecutorService übergeben.

// Executor service
ExecutorService executorService = Executors.newCachedThreadPool();

// Add jobs to executor service
for (int i = 0; i < 100; i++) {
    executorService.execute(new TestRunnable());
}

// Shutdown executor service
executorService.shutdown();
executorService.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);

Damit würden die Aufgaben abgearbeitet. Allerdings würde der ExecutorService nun bis zu einem Timeout noch bestehen bleiben. Stattdessen wird er im Beispiel kontrolliert heruntergefahren. Nach der Ausführung der shutdown-Methode nimmt der ExecutorService keine neuen Aufträge mehr an; bestehende Aufträge werden allerdings noch abgearbeitet. Über die Methode awaitTermination wird sichergestellt das der Service wartet, bis alle Aufgaben abgearbeitet sind. Bei der Methode wird ein Timeout angegeben, nach welchem der Service zwangsweise abgeschaltet wird. Damit werden die Aufgaben Stück für Stück abgearbeitet, ohne entsprechende viele Threads zu öffnen. Stattdessen werden Threads aus dem Threadpool wiederverwendet.

Exception-Hierarchie unter Java

Java nutzt, wie viele andere Sprachen, Exceptions zur Fehlersignalisierung und Fehlerbehandlung. Folgender Code würde hierbei dem Anschein nach alle Exceptions fangen:

try {
  // Do something wrong
} catch(Exception e) {
  // Gotta Catch 'Em All
}

An dieser Stelle trügt der Schein nicht. Allerdings werden nur einige Fehlerklassen gefangen, nämlich nur solche vom Typ Exception. Die Hierarchie der Fehlerklassen ist unter Java ein wenig differenzierter. In Java erbt jede Klasse implizit von der Klasse Object und so erbt auch die Klasse Throwable von dieser und implementiert das Interface Serializable.

Die Hierarchie der Klassen, welche für Fehlersignalisierung zuständig sind

Von der Klasse Throwable wiederum erben die Klassen Error und Exception. Fehler vom Typ Error stellen laut Definition immer Fehler innerhalb der JVM da, während Exceptions gewöhnliche Fehler des Programmes bzw. des Entwicklers sind. Sollen nun alle Fehlerklassen gefangen werden, so müsste der Quellcode wie folgt aussehen:

try {
  // Do something wrong
} catch(Throwable t) {
  // Gotta Catch 'Em All
}

Das Beispiel sollte nur als solches betrachtet werden, da es sich immer empfiehlt spezielle Fehler zu fangen und zu behandeln. Ein solch allgemeiner Fehlerhandler eignet sich nur für Spezialfälle wie z.B. das Logging nicht behandelter Fehler. Die Hierarchie verästelt sich anschließend noch weiter, so erben unterschiedlichste Klassen von der Klasse Error. Bei der Klasse Exception sieht dies ähnlich aus, allerdings existiert hier eine Besonderheit, die Klasse RuntimeException. Normalerweise muss eine Methode Exceptions, die sie wirft im Methodenkopf bekannt geben, wenn sie nicht in der Methode behandelt werden:

public static void example() throws Exception {
  throw new Exception();
}

Bei Klassen die von der Klasse RuntimeException erben muss diese Bekanntmachung im Methodenkopf nicht erfolgen. Sie werden trotzdem nach oben durchgereicht bis sie gefangen werden oder sich das Programm beendet, wenn die Behandlung der Exception nicht durchgeführt wurde.