Suche
Arno Haase über die Relevanz von Concurrency in Softwareprojekten

Effective Concurrency

Redaktion JAXenter

Arno Haase

Java bietet eine Vielzahl an Möglichkeiten mit Nebenläufigkeit (Concurrency) umzugehen. Es steht ein solides Memory Model und eine Vielzahl reifer und mächtiger Bibliotheken zur Verfügung. Doch wie setzt man Concurrency konkret in einem Projekt ein? Welches sind die Aspekte, die zwingend für Concurrency in einem Softwareprojekt sprechen? Und welche Werkzeuge sollte ein Entwickler kennen, um solide Concurrency-Lösungen zu bauen? Fragen an Arno Haase, freiberuflicher Softwareentwickler, Architekt, Coach und Berater, der auch auf dem JavaCodeCamp einen praxisorientierten Workshop zum Thema hält.

Concurrency ist ein Thema, das eigentlich seit vielen Jahren „gepredigt“ wird. Zugleich scheint es, als ob Concurrency in den meisten Projekten bislang noch keine oder nur eine untergeordnete Rolle spielt. Teilst du diese Beobachtung?

Arno Haase: Concurrency ist fast in jedem System zentral, sie wird aber oft von Frameworks und Bibliotheken erledigt. Ein Servlet-Container kümmert sich z.B. darum, parallel eingehende Requests effizient und robust auf Threads zu verteilen. Und für viele querschnittliche Themen wie Logging oder Monitoring, an denen viele Threads beteiligt sind, gibt es fertige Bibliotheken.

Bei der Anwendungsentwicklung kommt man mit Nebenläufigkeit vor allem in Berührung, wenn ein System die ausgetretenen Architekturpfade verlässt, wo jeder Request einem Thread zugeordnet ist. Dafür gibt es teilweise gute Business Cases: Bei einem Shop-System kann es besser sein, bei einer Suche nach einer Sekunde die bis dahin gefundenen Treffer anzuzeigen, als den Anwender sehr lange warten zu lassen, bis alle Treffer vorliegen.

Es gibt natürlich auch für solche Architekturen inzwischen Frameworks, aber dort hat man als Entwickler explizit mit Concurrency zu tun.

Viele Systeme – auch Neuentwicklungen – setzen aber nach wie vor auf „Thread per Request“, und dort kommt man als Entwickler tatsächlich kaum mit Concurrency in Berührung.

Was sind die Gründe dafür?

Arno Haase: Der Hauptgrund ist in meinen Augen, dass die klassische Architektur oft einfach reicht. Sie ist einfacher zu implementieren, und Usability ist gerade bei Systemen für den internen Gebrauch in Unternehmen oft eine nachgelagerte Priorität.

Java Code CampPurely Code: Erleben Sie Angelika Langer, Arno Haase, Kirk Pepperdine und Thilo Frotscher als Speaker auf dem Java Code Camp 2015 in Berlin! In einem komprimierten 2-Tage-Trainingsprogramm erhalten Sie wertvolle Tipps für besseren Code.

Alle weiteren Infos und Anmeldung auf java-code-camp.de

 

Welches sind die Aspekte, die zwingend für Concurrency in einem Softwareprojekt sprechen? Und welche tendieren eher dazu, ein System zu optimieren, ohne für es essenziell zu sein?

Arno Haase: Das A und O ist dabei, wie bei jeder Optimierung, eine klare Vorstellung von den Zielen, die man erreichen will. Wenn man nebenläufige Ansätze einführt, weil sie spannend sind und man Lust dazu hat, macht das ein System selten besser.

Ein erster Berührungspunkt mit Concurrency ist häufig die HTTP-Session. Besonders in Zeiten von AJAX greifen oft mehrere Threads parallel auf Session-Daten zu, und man muss dafür sorgen, dass das funktioniert.

Ein möglicher guter Grund für eine nicht-klassische, nebenläufige Architektur ist das Verbessern von Antwortzeiten, besonders im UI: Wenn man Teile der Arbeit in einem Hintergrundthread erledigt, kann ein Aufruf schneller zurückkehren.

Ein anderer guter Treiber kann die Verbesserung von Robustheit eines Systems sein, gerade unter Last. Wenn man z.B. aufwändige Reports in Hintergrundthreads erstellt, kann man steuern, wie viel Last das System mit Reporting erzeugen kann, und einen Zusammenbruch des Systems durch Reporting verhindern.

Welche Werkzeuge und Frameworks sollte man als Entwickler kennen, um fundierte Entscheidungen zu treffen und solide Concurrency-Lösungen zu bauen?

Arno Haase: Das ist eine kniffelige Frage – egal was ich alles aufzähle, die Liste ist nicht vollständig. Frameworks und Bibliotheken entwickeln sich gerade in diesem Bereich auch extrem schnell weiter.

Wichtiger als Frameworks sind meiner Ansicht nach die Konzepte dahinter. Ich würde mir deshalb für unterschiedliche Architekturansätze jeweils eine Lösung ansehen. Und wenn ich von einer Bibliothek höre, die sich nicht in meine bisherigen Kategorien einsortieren lässt, würde ich mir die auf jeden Fall ansehen.

Aktuell würde ich als Einstieg drei Ansätze empfehlen. Zunächst einmal wäre da Akka mit seinem Actor- und Future-basierten Ansatz, um Systeme „reaktiver“ zu machen.

Zweitens würde ich empfehlen, AtomicReference aus dem JDK zusammen mit immutable Klassen und CAS-Schleifen anzusehen. Diese Art von seiteneffektfreier Programmierung ist extrem leistungsfähig, und man kann damit überraschend leicht und robust threadsicheren Code schreiben.

Drittens würde ich mir die LMAX-Architektur und ansehen; das Disruptor-Framework ist ja Open Source. Es lagert die eigentliche Arbeit in einen einzigen Worker-Thread, und der Rest des Systems arbeitet diesem einen Thread zu. Das ist zwar ein sehr spezieller Ansatz, aber ich finde, man kann an ihm eine Menge über Concurrency im Allgemeinen lernen.

Verwandte Themen:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Effective Concurrency"

avatar
400
  Subscribe  
Benachrichtige mich zu:
bitte
Gast

es heisst „effective“, nicht „effektive“. oder gleich alles deutsch.