Java Concurrency Utilities

Größe: px

Ab Seite anzeigen:

Download "Java Concurrency Utilities"

Dörte Hofmeister
vor 6 Jahren
Abrufe

1 Java Concurrency Utilities Java unterstützt seit Java 1.0 Multithreading Java unterstützt das Monitorkonzept mittels der Schlüsselworte synchronized und volatile sowie den java.lang.object Methoden wait(), notify() und notifyall() Das ist eine vollständige Multithreading Unterstützung Aber: "Classical multi-threaded programming is very complex and error prone". (Java Tuning White Paper von Sun) Synchronisationskontrukte (z.b. Barriere) wurden in Applikationen immer wieder neu erfunden Eine Alternative zu Eigenbau Lösungen war lange Zeit die als Open Source verfügbare util.concurrent Klassenbibliothek von Doug Lea Basierend auf diesen Erfahrungen wurde 2002 unter der Leitung von Doug Lea der JSR 166 ins Leben gerufen mit dem Ziel "[to] provide functionality commonly needed in concurrent programs" Das Ergebnis sind die sogenannten "Concurrency Utilities", die sich im Package "java.util.concurrent" befinden und die seit Java 5 fester Bestandteil des JDK sind

2 Java Concurrency Utilities Grundidee: fertige Bausteine den Anwendungsentwicklern zur Verfügung zu stellen Bestandteile der Concurrency Utilities: Concurrent Collections: spezielle Implementierungen der Collection Framework Interfaces Map, Set, List, Queue, Deque. Executor Framework: ein Framework zur Ausführung asynchroner Tasks durch Threadpools. Synchronizers Diverse Hilfsklassen zur Koordination mehrerer Threads, zum Beispiel Semaphore oder CyclicBarrier Locks und Conditions: Flexiblere Objektrepräsentation des synchronized Schlüsselworts sowie der java.lang.object Monitor Methoden wait(), notify() und notifyall(). Atomic Variables: Erlauben die atomare Manipulation einzelner Variablen (CAS - Compare And Set) zur Implementierung von Algorithmen ohne Sperren (lock-free algorithms).

3 Java Executer Zur parallelen Ausführung eines Runnable ist immer ein Thread notwendig. Obwohl die nebenläufige Abarbeitung von Programmcode ohne Threads nicht möglich ist, sind doch beide sehr stark verbunden, und es wäre gut, wenn das Runnable von dem tatsächlich abarbeitenden Thread etwas getrennt wäre. Das hat mehrere Gründe: Schon beim Erzeugen eines Thread-Objekts muss das Runnable-Objekt im Thread-Konstruktor übergeben werden. Es ist nicht möglich, das Thread-Objekt aufzubauen, dann über eine JavaBean-Setter-Methode das Runnable-Objekt zuzuweisen und anschließend den Thread mit start() zu starten. Wird start() auf dem Thread-Objekt zweimal aufgerufen, so führt der zweite Aufruf zu einer Ausnahme. Ein erzeugter Thread kann also ein Runnable duch zweimaliges Aufrufen von start() nicht gleich zweimal abarbeiten. Für eine erneute Abarbeitung eines Runnable ist also mit unseren bisherigen Mitteln immer ein neues Thread-Objekt nötig. Der Thread beginnt mit der Abarbeitung des Programmcodes vom Runnable sofort nach dem Aufruf von start(). Die Implementierung vom Runnable selbst müsste geändert werden, wenn der Programmcode nicht sofort, sondern später (nächste Tagesschau) oder wiederholt (immer Weihnachten) ausgeführt werden soll. Wünschenswert ist eine Abstraktion, die das Ausführen des Runnable-Programmcodes von der technischen Realisierung (etwa den Threads) trennt. ThreadPool Eine wichtige statische Methode der Klasse Executors ist newcachedthreadpool(). Das Ergebnis ist ein ExecutorService-Objekt, eine Implementierung von Executor mit der Methode execute(runnable):

4 Java Executer Runnable r1 = new Runnable() public void run() { System.out.println( "A1 " + Thread.currentThread() ); System.out.println( "A2 " + Thread.currentThread() ); ; Runnable r2 = new Runnable() public void run() { System.out.println( "B1 " + Thread.currentThread() ); System.out.println( "B2 " + Thread.currentThread() ); ; ExecutorService executor = Executors.newCachedThreadPool(); Ausgaben: executor.execute( r1 ); executor.execute( r2 ); Thread.sleep( 500 ); executor.execute( r1 ); executor.execute( r2 ); executor.shutdown(); A1 Thread[pool-1-thread-1,5,main] A2 Thread[pool-1-thread-1,5,main] B1 Thread[pool-1-thread-2,5,main] B2 Thread[pool-1-thread-2,5,main] B1 Thread[pool-1-thread-1,5,main] B2 Thread[pool-1-thread-1,5,main] A1 Thread[pool-1-thread-2,5,main] A2 Thread[pool-1-thread-2,5,main]

5 Threads mit Rückgabe von Werten mittels callable und future Listing 2.13: com/tutego/insel/thread/concurrent/callabledemo.java, SorterCallable class SorterCallable implements Callable<byte[]> { private final byte[] b; SorterCallable( byte[] b ) { this.b = public byte[] call() { Arrays.sort( b ); return b; // gibt es nicht bei runnable Listing 2.14: com/tutego/insel/thread/concurrent/callabledemo.java, main() Ausschnitt byte[] b = new byte[ ]; new Random().nextBytes( b ); Callable<byte[]> c = new SorterCallable( b ); ExecutorService executor = Executors.newCachedThreadPool(); Future<byte[]> result = executor.submit( c ); Der ExecutorService bietet eine submit()-methode, die das Callable annimmt und einen Thread für die Abarbeitung aussucht.

6 Threads mit Rückgabe von Werte mittels callable und future Listing 2.15: com/tutego/insel/thread/concurrent/callabledemo.java, main() byte[] b = new byte[ ]; new Random().nextBytes( b ); Callable<byte[]> c = new SorterCallable( b ); ExecutorService executor = Executors.newCachedThreadPool(); Future<byte[]> result = executor.submit( c ); byte[] bs = result.get(); // blockiert erst jetzt, falls das Ergebnis noch nicht da ist System.out.printf( "%d, %d, %d%n", bs[0], bs[1], bs[bs.length-1] ); // 128, 128, 127 Vorteil: Ergebnisse von TASKS in Threads ausgeführt können angefordert werden. Blockierungsfreies arbeiten möglich...

7 Grob- und feingranulares Synchronisieren beim Erzeugen eines Singleton Ein Singleton verhindert mehrfache Erzeugung der Objekte einer Klasse privater Konstruktor verhindert Erzeugung von mehreren Objekten static Methode erlaubt Erzeugung eines einzigen Objektes Objekt wird in privater Variable gespeichert weitere Aufrufe liefern das vorher erzeugte Objekt static Methode muss bei parallelen Zugriff synchronisiert werden //Threadsicherer Singleton public class ST { private ST() { public static synchronized ST getinstance(){ return instance; //Threadsicherer und schneller Singleton? public class ST { private ST() { public static ST getinstance(){ //first check synchronized(st.class) { //second check return instance;

8 Grob- und feingranulares Synchronisieren beim Erzeugen eines Singleton public class ST { //Threadsicherer Singleton private ST() { public static synchronized ST getinstance(){ if (instance == null){ return instance; public class ST { //nicht threadsicher! private ST() { public static ST getinstance(){ synchronized(st.class) { return instance; public class ST { //Threadsicherer u. schnell? private ST() { public static ST getinstance(){ //first check synchronized(st.class) { //second check return instance; public class ST { Threadsicher und schnell! private static volatile ST instance = null; private ST() { public static ST getinstance(){ synchronized(st.class) { return instance;

Ähnliche Dokumente

Multithreading ab Java 5: Die neuen Concurrency APIs

Multithreading ab Java 5: Die neuen Concurrency APIs Java Concurrency Spezifiziert in JSR166 Ab Java 5 fester Bestandteil von Java Durch zusätzliche Library auch vor Java 5 vorhanden backport-util-concurrent