© DrHitch/Shutterstock.com
Shortcuts
Java 7

1 JSR 166y - Fork-Join-Framework

Das Fork-Join-Framework ist Teil des JSR 166y. Entwickelt und zur Verfügung gestellt werden die Abstraktionen des JSR 166 traditionell von Doug Lea [1]. Der Original-JSR-166 ging in Java 5 ein, erste Ergänzungen als JSR 166x folgten in Java 6. In Java 7 sind nun weitere Ergänzungen als 166y gekommen.

Shortcut Autorenteam


Wir wollen uns in diesem ersten Kapitel das Design des Fork-Join-Framework zusammen mit einigen Implementierungsdetails genauer ansehen. Im nächsten Kapitel diskutieren wir ausgehend von einem Benutzungsbeispiel, welche Rolle das Fork-Join-Framework für einige Erweiterungen in Java 8 spielen wird und wie sich damit die Benutzung von Arrays und Collections in Java zukünftig verändern wird. Doch bevor wir mit dem Fork-Join-Framework beginnen, sollten wir zur Abgrenzung einen kurzen Blick auf den ThreadPoolExecutor werfen.Der ThreadPoolExecutorDer ThreadPoolExecutor ist der Standard-Thread-Pool, der in Java im Rahmen des JDK zur Verfügung steht. Er war Teil des JSR 166 und ist dementsprechend mit Java 5 Bestandteil des JDK geworden. Wir haben ihm damals einen ausführlichen Artikel gewidmet [2]. Für die Diskussion ist wichtig, dass alle Tasks, die man zur Ausführung an den Thread-Pool übergibt, voneinander unabhängig sein müssen. Sie dürfen zum Beispiel nicht im Ergebnis voneinander abhängig sein, in einer festgelegten Reihenfolge abgearbeitet werden müssen oder anderweitig miteinander korrelieren. Es ist nicht immer ganz einfach, hier die potenziellen Korrelationen zu erkennen. Wenn man zum Beispiel in einem Eventserver das Senden der Events an die Clients über einen ThreadPoolExecutor abwickelt, so scheint dieser Ansatz erst einmal unproblematisch zu sein – das ist er aber leider möglicherweise nicht. Das Problem ist, dass die Reihenfolge der Events für einen Client unter Umständen nicht eingehalten werden kann. D. h. es kann vorkommen, dass die Reihenfolge, in der die Events an einen Client versandt werden, nicht mehr der Reihenfolge entspricht, in der sie an den ThreadPoolExecutor übergeben wurden. Wir haben also übersehen, dass die Reihenfolge der Events für einen Client eine Abhängigkeit darstellt, die der ThreadPoolExecutor nicht einhalten kann. Konkret kann dieses Reihenfolge-Problem zum Beispiel dadurch entstehen, dass zwei Events für den gleichen Client direkt hintereinander an den ThreadPoolExecutor übergeben werden. Jedem Event wird gleich ein Pool-Thread zugeordnet. Aufgrund des aktuellen Thread Schedulings wird aber der Thread für das erste Event angehalten, und dem Thread für das zweite Event wird die CPU zugeordnet. So wird dann das zweite Event vor dem ersten an den Client zugestellt. Lösen kann man das Problem dadurch, dass man nur jeweils ein Event pro Client an den ThreadPoolExecutor übergibt. Wenn mehrere Events für einen Client zu bear...

Shortcuts
Java 7

1 JSR 166y - Fork-Join-Framework

Das Fork-Join-Framework ist Teil des JSR 166y. Entwickelt und zur Verfügung gestellt werden die Abstraktionen des JSR 166 traditionell von Doug Lea [1]. Der Original-JSR-166 ging in Java 5 ein, erste Ergänzungen als JSR 166x folgten in Java 6. In Java 7 sind nun weitere Ergänzungen als 166y gekommen.

Shortcut Autorenteam


Wir wollen uns in diesem ersten Kapitel das Design des Fork-Join-Framework zusammen mit einigen Implementierungsdetails genauer ansehen. Im nächsten Kapitel diskutieren wir ausgehend von einem Benutzungsbeispiel, welche Rolle das Fork-Join-Framework für einige Erweiterungen in Java 8 spielen wird und wie sich damit die Benutzung von Arrays und Collections in Java zukünftig verändern wird. Doch bevor wir mit dem Fork-Join-Framework beginnen, sollten wir zur Abgrenzung einen kurzen Blick auf den ThreadPoolExecutor werfen.Der ThreadPoolExecutorDer ThreadPoolExecutor ist der Standard-Thread-Pool, der in Java im Rahmen des JDK zur Verfügung steht. Er war Teil des JSR 166 und ist dementsprechend mit Java 5 Bestandteil des JDK geworden. Wir haben ihm damals einen ausführlichen Artikel gewidmet [2]. Für die Diskussion ist wichtig, dass alle Tasks, die man zur Ausführung an den Thread-Pool übergibt, voneinander unabhängig sein müssen. Sie dürfen zum Beispiel nicht im Ergebnis voneinander abhängig sein, in einer festgelegten Reihenfolge abgearbeitet werden müssen oder anderweitig miteinander korrelieren. Es ist nicht immer ganz einfach, hier die potenziellen Korrelationen zu erkennen. Wenn man zum Beispiel in einem Eventserver das Senden der Events an die Clients über einen ThreadPoolExecutor abwickelt, so scheint dieser Ansatz erst einmal unproblematisch zu sein – das ist er aber leider möglicherweise nicht. Das Problem ist, dass die Reihenfolge der Events für einen Client unter Umständen nicht eingehalten werden kann. D. h. es kann vorkommen, dass die Reihenfolge, in der die Events an einen Client versandt werden, nicht mehr der Reihenfolge entspricht, in der sie an den ThreadPoolExecutor übergeben wurden. Wir haben also übersehen, dass die Reihenfolge der Events für einen Client eine Abhängigkeit darstellt, die der ThreadPoolExecutor nicht einhalten kann. Konkret kann dieses Reihenfolge-Problem zum Beispiel dadurch entstehen, dass zwei Events für den gleichen Client direkt hintereinander an den ThreadPoolExecutor übergeben werden. Jedem Event wird gleich ein Pool-Thread zugeordnet. Aufgrund des aktuellen Thread Schedulings wird aber der Thread für das erste Event angehalten, und dem Thread für das zweite Event wird die CPU zugeordnet. So wird dann das zweite Event vor dem ersten an den Client zugestellt. Lösen kann man das Problem dadurch, dass man nur jeweils ein Event pro Client an den ThreadPoolExecutor übergibt. Wenn mehrere Events für einen Client zu bear...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang