Neue Herausforderung (?)
- Multi-Core Dilemma: Sehr aktuelle Diskussion; durch java.util.concurrent angefacht, JSR 166, ebenso durch Multiprozessorarchitekturen. "Krieg der Kerne" iX. Patrick Leonhard-Blog.
- Steigerung der CPU-Frequenz nicht alleinige "Performanceschraube".
- Nur linearer Anstieg d. Stromverbrauchs bei Mehrkernarchitektur, platzsparend.
- www.despair.com
- Zukunftsprognosen: Cache-Vergößerung sorgt weiterhin f. Beschleunigung. Concurrent-Software wird für Nutzung immer wichtiger.
Begrifflichkeit – "Mehrfädigkeit".
Multithreading iRv Java EE. Einzig EJBs sind per se threadsave. Servlet 2.4 macht SingleThreaded Modell deprecated – kein Verlass. Spring nur Data Access Templates, Business Services bleiben in der Entwicklerverantwortung.
Cincurrency Utilities, Doug Lea, mit Java 1.5 in java.util.concurrent berücksichtigt. Concurrent Collections, Executor Framework. Synchronizers (Semaphore, CountDownLatch, CyclicBarrier, Exchanger), Locks (Objektpräsentation von synchronized) und Conditions, Atomic Variables.
Collection-synchronied grobgranular, skaliert schlecht, Multicoreunterstützung fehlt.
synchronized Wrapper-Beispiel.
Threadsafe und Concurrent – Unterscheidung.
Veränderte Semantik – Iteratoren bislang fail-fast, jetzt "weakly consistent".
Java 6: ConcurrentSkipListMap; Collection Interfaces (ab 1.5): Queue, BlockingQueue, ab 1.6: Deque ("Double Ended Queue"), Blocking Deque .
Executor Framework – Task durch Runnable beschrieben; Submission – Executor; SingleMethodInterface;
ThreadPoolExecutor – Subklasse ScheduledThreadPoolExecutor
Executors – Utility-Methoden;
Starten und stoppen des ThreadPools. ExecutorService – Lifecycle-Verwaltung; ThreadPool
Life-Demo
Schreibe einen Kommentar