1
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
[email protected]: 1.1
Schneller fahren aufmehr Spuren?
Multithreading im Zeichen vonMehrkernprozessoren
Steffen Schluff
Papick Garcia Taboada
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 2
Schneller fahren auf mehr Spuren?Überblick
• Die neue bekannte Herausforderung– Motivation, Probleme
• Multithreading und Enterprise Architekturen– Betrifft mich das auch?– Aber J2EE sagt doch…
• Was tun als Programmierer ???– Concurrency Utils
• Concurrent Collections, Executor Framework, ...– Tips, Tricks und Tools
• Javadoc, Lint, Immutability, ...
2
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 3
Schneller fahren auf mehr Spuren?Überblick
• Die neue bekannte Herausforderung– Motivation, Probleme
• Multithreading und Enterprise Architekturen– Betrifft mich das auch?– Aber J2EE sagt doch…
• Was tun als Programmierer ???– Concurrency Utils
• Concurrent Collections, Executor Framework, ...– Tips, Tricks und Tools
• Javadoc, Lint, Immutability, ...
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 4
Schneller fahren auf mehr Spuren?Überblick
• Die neue bekannte Herausforderung– Motivation, Probleme
• Multithreading und Enterprise Architekturen– Betrifft mich das auch?– Aber J2EE sagt doch…
• Was tun als Programmierer ???– Concurrency Utils
• Concurrent Collections, Executor Framework, ...– Tips, Tricks und Tools
• Javadoc, Lint, Immutability, ...
3
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 5
Das Multi-Core Dilemma…
Diskussionen gerade sehr aktuell…
java.util.concurrency Package…
JSR 166, JDK 1.5…
Java Concurrency in Practice…
Krieg der Kerne, iX…
Blog von Patrick Leonard, Diskussion of TSS…
Keynote von Tim Bray auf der WJAX 2006…
Verschiedene Sessions auf der JAX 2007
Patrick Leonard
Brian Goetz
Tim Bray
Doug Lea
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 6
Schneller fahren auf mehr Spuren?
• Die neue bekannte Herausforderung
• Multithreading und Enterprise Architekturen
• Was tun als Programmierer ???
4
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 7
Schluss mit Lustig?
• Seit 30 Jahren konstanter CPU Performance Anstieg
– Taktfrequenz,Ausführungs-optimierung,Cache
– SichererPerformanceGewinnfür Software
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 8
2007 und noch immer keine Lösung…
• CPU Taktfrequenz beginnt zu schwächeln
– Bisheriger Trend endet circa 2004
– Probleme: Wärmeentwicklung, Stromverbrauch, Leckströme
– Neue Ansätze versprechen immer wieder schnellere Prozessoren,bisher aber keine Produktionsreife erreicht
5
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 9
Entwicklung Taktfrequenz
0,1
1
10
100
1000
100001970 1975 1980 1985 1990 1995 2000 2005 2010
Jahr
Takt
frequ
enz
(Mhz
)
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 10
Free lunch is over?
Quelle: commons.wikimedia.org
6
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 11
Moore hat immer noch recht!
• Wachstum der Transistordichte noch vorhanden (Moore‘s Law)
• Hardware Hersteller satteln um– Hyperthreading, Caches
– Multicore-Technik• braucht wenig Platz• kein völlig neues Design• günstigere Energiebilanz
– Bei Erhöhung des Taktes steigt der Energiebedarf zum Quadrat– Bei Erhöung der Kerne steigt der Verbrauch „nur noch“ linear an
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 12
Wie sind die veränderten Prognosen für dieZukunft?
• Cache Wachstum beschleunigt Anwendungen auch weiterhin
• Aber Multithreading/Multicore beschleunigt Software nicht vonselbst
– Viele Anwendungen sind nicht für Mehrprozessorsysteme Entwickeltworden, laufen schließlich nur auf einem (meist langsameren Kern)
7
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 13
Wie läßt sich Hardware Wachstum weiteroptimal nutzen?
• Umdenken in der Entwicklung erforderlich
• „Concurrent software“ wird zunehmend wichtig werden
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 14
Neue Herausforderungen für SoftwareEntwickler
• Neue Architekturen, APIs und Technologien
• Umdenken im Bereich Testen und Performance
8
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 15
Offene Fragen,neue Problemstellungen
Increasing success bylowering expectations
http://www.despair.com
„No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them“
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 16
Multithreading, ist das was neues?
Wikipedia, Multithreading
Der Begriff Multithreading (auch Mehrfädigkeit) bezeichnet daszeitgleiche Abarbeiten mehrerer Threads (das sindAusführungsstränge innerhalb eines einzelnen Prozesses odereines Tasks).
9
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 17
Java Buzzwordbingo!
The Java programming language is a high-level language thatcan be characterized by all of the following buzzwords:
SimpleArchitecture neutralObject orientedPortableDistributedHigh performanceMultithreadedRobustDynamicSecure
Quelle: The Java Tutorials, The Java Technology Phenomenon
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 18
Java Buzzwordbingo!
The Java programming language is a high-level language thatcan be characterized by all of the following buzzwords:
SimpleArchitecture neutralObject orientedPortableDistributedHigh performanceMultithreadedRobustDynamicSecure
Quelle: The Java Tutorials, The Java Technology Phenomenon
10
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 19
Also…Java kann doch Multithreading!
• Java unterstützt seit Beginn Multithreading
– synchronized,– volatile– wait()– notify()– notifyAll()– Collections.synchronized[Collection|List|Set|Map](…)– U.s.w. …
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 20
Aber…Können wir es?
• In der Praxis aber schwer anwendbar
– Multithread Programmierung syntaktisch einfach,aber keineswegs trivial!
– Komplizierte Konstrukte mit niedrigem Abstraktionsgrad
– In reiner Form ungeeignet für Anwendungsentwicklung
11
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 21
Wie gut ist die eigene Lösung?
• Jeder kocht sein eigenes Süppchen
– Viele hausgemachte Ad-Hoc Lösungen
– Eigene Lösungen oft unausgegoren und nur schwer testbar
� Einarbeitungszeit für neue Mitarbeiter?
� Testbarkeit?
���� Dokumentation?
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 22
Java, Threads und…CPUs?
Angenommen,wir (Entwickler) sind in der Lage ConcurrentSoftware zu entwickeln,wie werden meine Threads auf CPUs verteilt?
12
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 23
Mehrere CPUs in Java nutzen
• Java stellt keine eigene Funktionenzur Prozesskontrolle undProzesssteuerung bereit
– Je nach OS verschiedeneAnsätze
– OS Frage als Platform (wieder)Aktuell?
Verschiedene Arten von Threads(aus Sicht der VM)
Green ThreadsThreads „nurinnerhalb“ einer VM
Native Threads (heuteStandard)
Java Threads werdenauf Betriebsystemprozesseabgebildet Betriebsystemist für Scheduling
zuständig
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 24
CPU Affinity?
Bug ID: 4234402Synopsis: (thread) Thread.setCPUAffinity?State: Closed, will not be fixed
(…)But this is ignoring the basic fact that only the mostsophisticated Java users could expect to gain real advantagewith such a feature (i.e. by making better scheduling choices thanthe operating system would make without use of the feature)(…)
Quelle: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4234402
13
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 25
Java & Windows
• Native Threads sind Win32 Threads
– Windows ist für Schedulingund Synchronization zuständig
– Tools zur Überwachung sind imWindows Softwareumfeld zu suchen
– „Leistung“ (perfmon.msc) bietetviele Überwachungsmöglichkeiten
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 26
Visualisierung mit Perfmon.msc
14
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 27
Schneller fahren auf mehr Spuren?
• Die neue bekannte Herausforderung
• Multithreading und Enterprise Architekturen
• Was tun als Programmierer ???
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 28
Wo helfen viele Prozessoren?
• Virtualisierung von Rechnern– Xen, VM Ware, OpenVZ, u.v.a.
• Erhöhung der Performanceeinzelner Server bzw. Dienste die bereitsMultithreaded sind
– Application Server– Mail Server– U.s.w.
15
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 29
Eigentlich nichts Neues
• „Enterprise“ Hardware schon seit längerer ZeitMultiprozessorbasiert– Symmetrisches Multiprocessing ist seit Ende der 80er Jahre die
Standard-Architektur für Multiprozessor-Maschinen mit bis zu 16CPUs.
• Java Enterprise Edition adressiert thread safety und concurrencybereits in der Architektur
• Warum also erst jetzt die ganze Diskussion?
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 30
Hardware…
16
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 31
Und (Enterprise) Software…
• Java wird stark im Umfeld Unternehmenskritischer Anwendungeneingesetzt
– Java Enterprise Edition
• Java EE Architekturen vereinfachendie Softwareentwicklung
- Laufzeitumgebung- Schnittstellen- Programmiermodell- Vorschriften bzw. Restriktionen
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 32
Java EE Architektur, EJBs
The Enterprise JavaBeans architecture will make it easy to writeapplications: application developers will not have to understand low-leveltransaction and state management details, multi-threading, connection pooling, orother complex low-level APIs.
The enterprise bean must not attempt to manage threads. The enterprise beanmust not attempt to start, stop, suspend, or resume a thread, or to change athread’s priority or name. The enterprise bean must not attempt to manage threadgroups.These functions are reserved for the EJB container. Allowing the enterprise beanto manage threads would decrease the container’s ability to properly manage theruntime environment.
Quelle: Enterprise JavaBeans 3.0 Final Release
17
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 33
Java EE Architektur
The Enterprise JavaBeans architecture will make it easy to writeapplications: application developers will not have to understand low-leveltransaction and state management details, multi-threading, connection pooling, orother complex low-level APIs.
The enterprise bean must not attempt to manage threads. The enterprise beanmust not attempt to start, stop, suspend, or resume a thread, or to change athread’s priority or name. The enterprise bean must not attempt to manage threadgroups.These functions are reserved for the EJB container. Allowing the enterprisebean to manage threads would decrease the container’s ability to properly managethe runtime environment.
Quelle: Enterprise JavaBeans 3.0 Final Release
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 34
Java EE und „thread safety“
• Prinzipiell sorgt ein Application Server dafür, dass dieKomponenten sich nicht um „thread safety“ kümmern müssen
– Das bezieht sich aber nur auf EJBs• z.Bsp. werden SLSB werden mehrfach instanziert um exklusivität
(und dadurch Threadsafety) während eines Methodenaufrufs zugarantieren
– Servlets sind Singletons und werden u.U. von verschiedenen Threadsgleichzeitig aufgerufen, müssen also Threadsafe sein.
• Thread Synchronization ist keine Lösung
• Das Interface SingleThreadModel ist „deprecated“seit Servlet API 2.4
18
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 35
Java EE und „thread safety“ Fazit
Nur EJB Anwendungen sind „out of the box“ thread safe
– Gut:• Entwickler muss sich nicht um Threads und Threadsafety kümmern
• Anwendung skaliert in Bezug auf Anzahl der Anfragen/ Clients ohnezutun des Entwicklers
– Schlecht:• Entwickler kann keine Threads starten und somit keine
Lösungsansätze anstreben, die Nebenläufigkeit einbeziehen
• Anwendung skaliert nicht in Bezug auf Komplexität derBusinesslogik wenn sequentielle Algorithmen versagen
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 36
Problembereich Webanwendungen
• Thread safety in Webanwendungen nicht immer gegeben
– „Wir brauchen keine EJBs. Wir wollen nur eine einfacheWebanwendung bauen“
• Anmerkung: Es gibt nicht sowas wie eine „EinfacheWebanwendung“
– Viele Webanwendungen verzichten auf EJB-Schicht
– Entwickler müssen sich mit „thread safety“ auseinandersetzen
• Was kümmer mich „thread safety“? Bin doch J2EE Entwickler…• „Know How“ vorhanden?
19
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 37
Ist Spring die Rettung?
• Teilweise…
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 38
Solving other peoples‘ problems…
Die mit Spring mitgelieferten „Data Access Templates“sind thread safe.
Dadurch wird die Implementierung einer DAO Schicht innerhalbeiner Webanwendung deutlich vereinfacht.
20
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 39
Vorsicht…
• Die in Spring konfigurierte business Schicht (services) müssen jenach Umfeld „thread safe“ entwickelt werden.
• Dennoch muss sich ein Entwickler mit der Tatsacheauseinandersetzen, dass thread safety in einer Webanwendungnicht gegeben ist und das entsprechende Know How aufbauen
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 40
Project Danger?
21
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 41
Schneller fahren auf mehr Spuren?
• Die neue bekannte Herausforderung
• Multithreading und Enterprise Architekturen
• Was tun als Programmierer ???
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 42
Der Silberstreifen am Horizont
• Pionierarbeit durch Doug Lea– Web Page und Veröffentlichungen seit Ende der 90er– Entwicklung eigener Java API (EDU.oswego.cs.dl.util.concurrent)
• Einrichtung JSR 166– „... provide functionality commonly needed in concurrent programs.“– Geleitet durch Doug Lea
• Ergebnis „Concurrency Utilities“– Seit Java 5 fest im JDK (java.util.concurrent)– Etwas untergegangen im Sprachfeature Trubel– Diverse Erweiterungen in Java 6
22
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 43
Concurrency Utilities Bestandteile (1)
• Stellt fertige Bausteine zur Verfügung– Für alle Arten von Entwicklern (Anwendung, Server, Concurrent, ...)
• Concurrent Collections– Spezielle Implementierungen von Map, Set, List, Queue, Deque
• Executor Framework– Framework zur Ausführung asynchroner Tasks
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 44
Concurrency Utilities Bestandteile (2)
• Synchronizers– Hilfsklassen zur Koordination mehrerer Threads– Semaphore, CountDownLatch, CyclicBarrier, Exchanger
• Locks und Conditions– Lock ist Objekt Repräsentation von synchronized– Condtion kapselt Monitor Methoden wait(), notify und notifyAll()
• Atomic Variables– Atomare Manipulation einzelner Variablen– Erlaubt Hardware Compare-And-Swap (CAS) zu nutzen
23
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 45
Klassiker
• „Thread-Safe“ Datenstrukturen in Java bereits vorhanden– Vector, Hashtable– Synchronized Wrapper aus java.util.Collections: synchronizedList(), ...
• Sicherheit durch Synchronisierung aller Zugriffsmethoden– Grob granulares Locken der ganzen Collection– Skaliert schlecht bei Zugriff aus vielen Threads („Multicore anyone?“)
• Synchronisierung durch Client häufig notwendig– Mehrschrittige Operationen (deleteLast, putIfAbsent, ...)– „Fail-fast“ Iteratoren (ConcurrentModificationException)
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 46
Überraschung
List<String> ls =
Collections.synchronizedList(new ArrayList<String>());
...
// Verhalten kann undeterministisch sein
// Kann ConcurrentModificationException werfen
Iterator<String> i = ls.iterator();
while (i.hasNext()) {
foo(i.next());
}
...
24
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 47
Gut Ding will Weile haben
List<String> ls =
Collections.synchronizedList(new ArrayList<String>());
...
// Client synchronisiert
// Blockiert anderen Zugriff während Iteration
synchronized(ls) {
Iterator<String> i = ls.iterator();
while (i.hasNext()) {
foo(i.next());
}
}
...
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 48
Concurrent Collections
• Unterscheidung „Thread-Safe“ und „Concurrent“– Neue Implementierungen der klassischen Strukturen (List, Map, Set)– Ab Java 6 auch für SortedMap und SortedSet
• Erlauben nicht blockierenden (skalierbaren) parallelen Zugriff– Standardfall: Paralleles Lesen aus mehreren Threads– Nachteil: Kleinere semantische Anpassungen notwendig
• Iteratoren „weakly consistent“ statt „fail-fast“– Kein komplettes Locken und keine ConcurrentModificationException– Iterator darf Änderungen seit seiner Erzeugung ignorieren
25
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 49
Klassiker, again
• ConcurrentHashMap– Fein granulareres Locken erlaubt paralleles Lesen und Schreiben– Kein Client-Lock, dafür neue atomare Methoden (putIfAbsent, ...)
• CopyOnWriteArrayList / CopyOnWriteArraySet– Array basierte Liste, Veränderung führt zu neuer Array Kopie– Ideal falls lesen deutlich häufiger als schreiben
• ConcurrentSkipListMap (ab Java 6)– Implementierung des SortedMap Interface– Wird auch verwendet für ConcurrentSkipListSet
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 50
Neuzugänge vorne anstellen
• Neues Collection Interface Queue– Datenstruktur, die Elemente für eine Verarbeitung bereit hält
• Neues Collection Interface BlockingQueue– Methoden take() und put(), die bei leerer / voller Queue blockieren– Für Erzeuger-Verbraucher Architekturen (z.B. Thread Pools)
• Neue ColIection Interfaces Deque und BlockingDeque (ab Java 6)– Deque steht für Double Ende QUEue– Für „Work Sharing“ und „Work Stealing“ Architekturen
26
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 51
Executor Framework (1)
• Ermöglicht asynchrones Ausführen von Tasks in Thread Pools– Trennung von Aufgabe (Task) und deren tatsächlicher Ausführung
• Task wird durch Interface Runnable beschrieben– Alter Bekannter aus JDK 1.0
• Keine Aussage wann oder wie Tasks ausgeführt wird (Execution)– Schnittstelle nötig für Taskübergabe zur Ausführung (Submission)
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 52
Executor Framework (2)
• Neues Interface Executor– Executor Objekte können Tasks zur Ausführung entgegen nehmen
• Konkrete Art der Ausführung von Implementierung abhängig
• Executor Implementierung bestimmt „Execution Policy“– Ressourcen Verwendung, Ausführungsreihenfolge, ...– Execution Policy leicht konfigurierbar je nach Hardware
27
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 53
Executor meets Runnable
• Executor Interface
public interface Executor {
void execute(Runnable command);
}
• Runnable Interface
public interface Runnable {
void run();
}
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 54
Neues Code Idiom
• Aus alt:
new Thread(myRunnable).start()
• Mach neu:
myExecutor.execute(myRunnable)
28
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 55
Woher nehmen? (1)
• Klasse ThreadPoolExecutor direkt instanziieren– Oder Subklasse ScheduledThreadPoolExecutor
• Utility Klasse Executors– Analogon zu Collections Klasse des Collection Frameworks
• Executors enthält diverse statische Factory Methoden– Leichtes Executor Erzeugen mit gängigen Voreinstellungen
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 56
Woher nehmen? (2)
• newFixedThreadPool(int nThreads)– Feste Größe, ersetzt unerwartet beendete Threads
• newCachedThreadPool()– Unbegrenzter Größe, wächst und schrumpft nach Bedarf
• newSingleThreadExecutor()– Ein Arbeitsthread, Tasks werden sequentiell abgearbeitet
• newScheduledThreadPool(int corePoolSize)– Für verzögerte und periodische Ausführung (Timer Ersatz)
29
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 57
Stets zu Diensten (1)
• Konkrete Executor Implementierung beeinflußt Anwendung– Executor kann z.B. neue Threads erzeugen
• Executor stellt Dienst (Service) für Anwendungen zur Verfügung
• Verwaltung über eigene Lifecycle Methoden wünschenswert– Dienste können gestartet und gestoppt werden
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 58
Stets zu Diensten (2)
• Eigenes Interface ExecutorService– Subinterface von Executor
• ExecutorService definiert Lifecycle– Drei Zustände: „Running“, „Shutting Down“ und „Terminated“
• Zustandswechsel durch entsprechende Methoden– shutdown(), shutdownNow(), awaitTermination(), ...
• Rückgabetyp der statischen Executors Factory Methoden– implementiert von ThreadPoolExecutor
30
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 59
Demo
Demo „ Concurrency Utilities“
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 60
Blick in die Zukunft (1)
• Task Abstraktion durch Runnable hat Schwächen– Keine Ergebnisrückgabe (nur Seiteneffekte), keine checked Exceptions
• Callable Interface für ergebnisbehaftete Tasks
public interface Callable<V> {
V call() throws Exception;
}
• Callable Objekte ausführbar durch ExecutorService– submit() Methoden, geben Future Objekte zurück
public interface ExecutorService { // Auszug
<T> Future<T> submit(Callable<T> task);
}
31
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 61
Blick in die Zukunft (2)
• Future beinhaltet Ergebnis eines asynchronen Aufrufs (Callable)– Ergebnis abfragbar durch Methode get()
• Future Interface enthält auch Lebenszyklus eines Tasks– Berechnung kann bei Zeitüberschreitung unterbrochen werden
public interface Future<V> { // Auszug
V get() throws InterruptedException, ExecutionException;
boolean cancel(boolean mayInterruptIfRunning);
}
• Runnable können in Callable Objekte umgewandelt werden– Util Methode callable() in Klasse Executors– Methode submit() in Interface ExecutorService ist für Runnable überladen– Klasse FutureTask kann Callable Objekte als Runnable wrappen
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 62
Sekunde…
• Wenn noch Zeit ist…
32
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 63
Das leidige Dokumentieren (1)
• Korrektes Verhalten einer Klasse ist definierbar (dokumentierbar)– Invarianten, Postconditions, Preconditions– Grundvoraussetzung für Aussagen über „Thread-Safety“
• „Thread-Safe“ Klasse impliziert mehrere Dinge– Konkurrierende Aufrufe beeinträchtigen korrektes Verhalten nicht– Synchronisierung unnötig durch Aufrufer
• Zwei Dokumentationsebenen (Schnittstelle vs. Implementierung)– Schnittstelle: Ist Locken durch Client möglich?, ...– Implementierung: Welche Locks schützen was?, ...
• Alles andere ist raten!
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 64
Das leidige Dokumentieren (2)
• Bisher keine definierte Art der Dokumentation– „[...] a class must [...] document in prose [its] level of thread safety [...]“
• Effective Java Item 52 „Document Thread Safety“– Taxonomie zur Dokumentation von Klassen– Immutable, T-safe, Conditionally T-safe, T-compatible, T-hostile
• Concurrency Annotations aus „Java Concurrency in Practice“– Klassen: @Immtuable, @ThreadSafe, @NotThreadSafe– Felder und Methoden: @GuardedBy(String lock)
• Bekanntestes Antibeispiel aus JDK Javadoc– SimpleDateFormat (bis einschließlich Java 1.3)
33
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 65
Lint Werkzeuge
• Werkzeug zur statischen Codeanalyse– Ursprünglich Kommandozeilentool aus der C Welt
• Alarmiert über verdächtige Sprachkonstrukte– Aber nicht zwangsläufig falsche Konstrukte
• Diverse Tools für Java verfügbar– FindBugs, PMD, Checkstyle, ...– JSR 305 „Annotations for Software Defect Detection“ (Einrichtung 2006)
• FindBugs besitzt eigene Kategorie „Multithreaded correctness“– Double-checked locking, Spin loops, Unreleased locks, ...– Prüft auch Concurrency Annotations („Java Concurrency in Practice“)
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 66
Testen (1)
• Concurrent Software ist schwerer testbar als sequentielle– Fehler nicht deterministisch und schwerer reproduzierbar
• Testcode ist ebenfalls Concurrent Software– Tests können Fehler im Anwendungscode maskieren
• Phänomen bekannt als „Heisenbug“– „A bug that disappears or alters its behavior when one attempts to
probe or isolate it.“ („http://www.jargon.org“)– Tests möglichst frei von Synchronisierung
34
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 67
Testen (2)
• Concurrent Bestandteile einer Anwendung isolieren– Häufig beschränkte Systemteile (Workflows, Pools, Queues, ...)– Oberstes Ziel ist isolierte Testbarkeit
• Fehler sind zufällige Ereignisse– Testlaufzeiten erhöhen– Zustandsraum (Ausgangszustände und Eingangsgrößen) variieren
• Prozessorzahl der Testplattform berücksichtigen– Zu wenig Threads verhindern Preemption und Thread-Interaktion– Faustregel: Mehr aktive Threads als Prozessoren
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 68
Immutability
• Bequeme Möglichkeiten Synchronisierung zu vermeiden– Daten auf einen Thread beschränken (Thread Confinement)– Unveränderliche Objekte verwenden (Immutability)
• Immutable Objekte...– können nach Erzeugung nicht verändert werden– geben „this“ Referenz nicht während der Erzeugung weiter– besitzen nur „final“ Felder (Initialization Safety)
35
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 69
Effectively immutable
• Objekte können „Effectively immutable“ sein– zustandsändernde Methoden nach Erzeugung nicht mehr aufrufen– aber Objekt Veröffentlichung muß sicher sein (Safe Publication)
• Objektreferenz werden sicher veröffentlicht in...– static initializer Blöcken– volatile Feldern bzw. AtomReference Objekten– final Feldern bei Erzeugung von Objekten– Lock geschützten Feldern
• Danach Verwendung als de facto immutable
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 70
Literaturhinweise
• Java Concurrency in PracticeSprache: EnglischBroschiert - 403 Seiten - Addison-Wesley LongmanErscheinungsdatum: 25. Mai 2006ISBN: 0321349601
• Concurrent Programming in JavaSprache: EnglischBroschiert - 411 Seiten - Addison-Wesley LongmanErscheinungsdatum: 31. Dezember 1999ISBN: 0201310090
• Effective Java. Programming Language Guide.Sprache: EnglischBroschiert - 252 Seiten - Addison WeselyErscheinungsdatum: 5. Juni 2001ISBN: 0201310058
36
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 71
Links
• Java 6 java.util.concurrent API Docs– http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html
• Doug Lea Homepage– http://gee.cs.oswego.edu/dl
• JSR 166 Homepage– http://jcp.org/en/jsr/detail?id=166
• The Free Lunch Is Over (Online Artikel)– http://www.gotw.ca/publications/concurrency-ddj.htm
• FindBugs Homepage– http://findbugs.sourceforge.net
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 72
(Effective Java, Item 30: „Know and use the libraries“)
If you remember one thing
„To summarize, don‘t reinvent the wheel.“
37
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
[email protected]: 1.1
Vielen Dank für IhreAufmerksamkeit !
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 74
Papick Garcia Taboada
Software Architekt
Technologie-Scout
Beratung
Projekte
Training
38
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 75
Steffen Schluff
Beratung
Projekte
Training
Im a pogramar
Iam a programer
I'm a programor
I write code
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
[email protected]: 1.1
? ???
?Noch Fragen…
39
© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 77
) Akademie ) ) Beratung )
„Orientierung“ in Objekten
• Schulungen, Coaching, Weiterbildungsberatung, Train & Solve-Programme
• Methoden, Standards und Tools für die Entwicklung von offenen, unternehmens- weiten Systemen
• Schlüsselfertige Realisierung von Software• Unterstützung laufender Projekte• Pilot- und Migrationsprojekte
) Projekte )