Vor ein paar Jahren sich die Entwicklung von CPUs grundlegend verändert: Statt immer höhere Taktraten zu erzielen setzen Prozessorhersteller auf mehrere Prozessorkerne, die parallel arbeiten. Das volle Leistungspotential können damit auch nur noch Programme ausschöpfen, die parallel mit mehreren Prozessen oder Threads arbeiten. Klassische Programmiersprachen wie C, C++ und Java verlangen vom Programmierer, dass sie selbst für die Parallelisierung Sorge tragen (explizite Parallelisierung). Einfacher zu handhaben sind Programmiersprachen die eine implizite Parallelisierung unterstützen, also keine weiteres Zutun seitens des Entwicklers bedürfen. Insbesondere funktionale Sprachen wie Haskell und Erlang sind besonders dafür geeignet, da sich die Programme hier naturgemäß in parallel abarbeitbar Einheiten unterteilen lassen.

Dennoch hat Java gegenüber Compiler Sprachen, die direkt Maschinen-Code erzeugen, hier Vorteile. Zumindest theoretisch kann der Java Bytecode vor der Ausführung auf Parallelisierbarkeit analysiert und entsprechend der vorhandenen CPU kompiliert werden. Zum anderen kann der Garbage Collector nebenläufig arbeiten und parallel nicht mehr benötigten Speicher aufräumen. Wie gut das bereits 2006 skalierte, kann man hier nachlesen.

Neben diesen von der JVM gebotenen Mechanismen für Parallelisierung sind vor allem folgende Techniken in der Java Welt relevant:

  • Explizites Multi-Threading: Java SE bietet hierfür die Klasse Thread und den Concurrent Utilities ab Java 5. Für letzeres hat beispielsweise oio eine gute Deutsche Einführung.
  • Parallelisierung von Client-Requests: Der typische Server verarbeitet die Anfragen parallel; so auch Servlet- und EJB-Container. Jede Anfrage wird für sich jedoch sequentiell abgearbeitet. Anwendung für J2EE/JEE Application Server sollten keine eigenen Threads starten.
  • Nachrichten-basierte Parellelisierung: Nachrichten werden hier parallel von mehreren Cosumern verarbeitet. Meist mit einer JMS-basierten MOM beziehungsweise innerhalb eines J2EE/JEE Applikationsservers. Die völlig asynchrone Funktionsweise erfordert oft eigene Mechanismen für die Zusammenführung von Ergebnissen.
  • Grid und Computing-Cluster: Hier wird die Bearbeitung nicht nur auf mehrere CPUs sondern auch mehrere Rechner aufgeteilt. Interessante Produkte sind hier Oracle Coherence (früher Tangosol) und Terracota.

Nach diesem grundlegenden Überblick über Parallelisierungstechniken, wird es im nächsten Teil um neue Möglichkeiten gehen, die Java 7, APIs für implizites Multithreading und Java EE 6 bieten beziehungsweise bieten werden.

3 Antworten zu “Parallelisierung mit Java”
  1. Michael.Nischt sagt:

    Neben JMS scheint Kilim eine interessante alternative fuer nachrichten-basierte Parellelisierung zu sein.

  2. Markus Junginger sagt:

    Hi Michael, Schon mal was mit gemacht? Spannend fand ich bei Kilim, dass es hier einen >>bytecode postprocessor (a “weaver”)<< gibt. Mal näher anschauen bei Gelegenheit…

    Mich interessieren gerade ganz einfach zu verwendende Ansätze, also z.B. eine parallelisierte for Schleife. Für .NET gibt es hier eine Erweiterung und für Java gibt es zumindest ein kommerzielles Produkt. Mehr davon dann im nächsten Artikel. Kennt jemand ähnliche Ansätze?

  3. Michael.Nischt sagt:

    Hi Markus,

    Ich hab Kilim noch nicht verwendet, aber die Performance scheint sehr gut zu sein wenn man die Kilim-Erlang Benchmarks sieht… Ein Vergelich zu Scala Actors waere auch interesannt..

    Zu parallelisierten for-loops faellt mir als erstes SUN’s Fortress ein (http://research.sun.com/projects/plrg/). Ansonten wieder Scala und diese einfach selbst implementieren, bzw vielleicht gibt es auch schon Libraries, leider kenne ich keine..

    Hier mal ein Script zu parallel for-loops in Scala den ich gerade geschrieben habe (quick & dirty):
    http://gestalt.monoid.net/stuffu/ParallelArray.scala

    Allerdings denke ich nicht, dass es sich derzeit, mit 1-8 cpu cores, lohnt auf dieser Ebene zu optimieren. Mann brauchte schon einen recht grossen Datenstrom und die Berechnungen in der Schleife selbst muessten auch eher komplex sein, damit der Overhead vernachlaessigbar ist…

    Anyway, bin gespannt was du noch so auskramst.. :-)

Hinterlasse einen Kommentar