Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Java 7: Fork-Join-Framework und Phaser
Java 7: Fork-Join-Framework und Phaser
Java 7: Fork-Join-Framework und Phaser
Ebook54 pages29 minutes

Java 7: Fork-Join-Framework und Phaser

Rating: 0 out of 5 stars

()

Read preview

About this ebook

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.
LanguageDeutsch
Release dateSep 15, 2012
ISBN9783868024272
Java 7: Fork-Join-Framework und Phaser

Read more from Angelika Langer

Related to Java 7

Titles in the series (100)

View More

Related ebooks

Programming For You

View More

Related articles

Reviews for Java 7

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    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

    Enjoying the preview?
    Page 1 of 1