Erfreu Dich an Millionen von E-Books, Hörbüchern, Magazinen und mehr

Nur $11.99/Monat nach der Testversion. Jederzeit kündbar.

Java 7: Fork-Join-Framework und Phaser

Java 7: Fork-Join-Framework und Phaser

Vorschau lesen

Java 7: Fork-Join-Framework und Phaser

Länge:
54 Seiten
29 Minuten
Herausgeber:
Freigegeben:
15. Sept. 2012
ISBN:
9783868024272
Format:
Buch

Beschreibung

Im zweiten Band des Java-7-shortcuts von Angelika Langer und Klaus Kreft werden weitere wichtige Neuerungen vorgestellt und erläutert. Die beiden Java-Experten konzentrieren sich dabei in den ersten Kapiteln auf das Fork-Join-Framework, einen Teil des JSR 166y. Es geht um das Design des Frameworks, Details zu dessen Implementierung und die Konsequenzen für die zukünftige Benutzung von Arrays und Collections in Java 8. Das Framework wird außerdem anhand eines Benutzungsbeispiels veranschaulicht. Im dritten Kapitel betrachten die Autoren den Phaser, einen Synchronizer im JDK Package java.util.concurrent, der in Phasen abläuft und deutlich flexibler ist als die existierenden Synchronisationsmittel CountDownLatch und CyclicBarrier.
Herausgeber:
Freigegeben:
15. Sept. 2012
ISBN:
9783868024272
Format:
Buch

Über den Autor


Ähnlich wie Java 7

Titel in dieser Serie (40)

Ähnliche Bücher

Ähnliche Artikel

Buchvorschau

Java 7 - Angelika Langer

Angelika Langer, Klaus Kreft

Java 7

Fork-Join-Framework und Phaser

ISBN: 978-3-86802-427-2

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

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.

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 ThreadPoolExecutor

Der 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

Sie haben das Ende dieser Vorschau erreicht. , um mehr zu lesen!
Seite 1 von 1

Rezensionen

Was die anderen über Java 7 denken

0
0 Bewertungen / 0 Rezensionen
Wie hat es Ihnen gefallen?
Bewertung: 0 von 5 Sternen

Leser-Rezensionen