© Excellent backgrounds/Shutterstock.com
Java Magazin
Ein Lock mit Höhen und Tiefen

Emotional StampedLock

Die Core Java Packages haben in den letzten Versionen immer mal wieder ein paar Werkzeuge für die Bewältigung von Nebenläufigkeitsproblemen bekommen. Ein neuer Vertreter ist der StampedLock in JDK 8. Grund zur Freude oder Grund für Frust? Wir sehen uns die Sache an.

Sven Ruppert, Heinz Kabutz


Java 8 Tooling in Eclipse

Aus dem Java-EE- und dem Java-SE-Umfeld wissen wir, was es bedeutet, sich mit der Problematik der Nebenläufigkeit auseinander zu setzen. Von akademischer wie praktischer Seite wurden und werden immer wieder verschiedenste Ansätze eingeführt. Gab es früher nur ein Synchronized, kamen später die Semaphoren und Ähnliches dazu. Was also ist das Neue am StampedLock? Wie ist er zu verwenden? Welche Besonderheiten gibt es?

Why Synchronizers?

Zum Einstig nochmals kurz die Fragestellung, warum eigentlich Synchronisationsmittel verwendet werden müssen. Mithilfe der Synchronizers bleiben verteilte mutable Zustände konsistent. Das ist immer dann notwendig, wenn es keine anderen technischen Möglichkeiten gibt, den Zustand des Systems in einer zustandslosen oder rein lokalen, nicht verteilten Version zu realisieren. Zu bedenken ist hier, dass immutable Zustände den Garbage Collector stark beanspruchen können und nicht verteilte/lokale Zustände einen höheren Speicherverbrauch zur Folge haben. Manche unserer Kunden haben HashMaps mit Dateninhalt in der Größenordnung von um die hundert GB.

Coarse-grained Locking

Wie also geht man nun mit der Problematik des Lock­ings um? Eine einfache Methode ist das harte bzw. grobe Locking. Hierbei hat man sicherlich eine Menge Probleme umgangen, jedoch stellt sich auch nicht der gewünschte Erfolg ein. Es wird mehr oder weniger alles seriell abgearbeitet, was zur Folge hat, dass nur ein Core der verfügbaren CPUs mit der Lösung der Aufgabe beschäftigt werden kann. Ziel ist also eine möglichst ausgeglichene Locking-Strategie, die es ermöglicht, möglichst viele Cores gleichzeitig zu verwenden.

„good“ and „bad“ ContextSwitches

Gehen wir also im Folgenden davon aus, dass wir eine erhöhte Auslastung der Cores erreichen. Das bedeutet allerdings auch, dass der jeweilige Kontext für den ­Thread gewechselt werden muss. Man spricht in diesem Zusammenhang vom ContextSwitch. Nun liegt es in der Natur der Sache, dass es gute und schlechte ContextSwitches gibt. Was ist nun der „gute“ und was ist der „schlechte“ ContextSwitch?

Der gute ContextSwitch: Hier sprechen wir von einem Thread, der seine zur Verfügung stehende Rechenzeit voll ausnutzen konnte. Solch ein Thread Context kann normalerweise innerhalb von einem Clock Cycle ein swap out erfahren und ist offiziell unter dem Begriff „Involuntary ContextSwitch“ bekannt. Wir sprechen von einem schlechten ContextSwitch, wenn der Thread stoppen muss, da eine benötigte Ressource...

Java Magazin
Ein Lock mit Höhen und Tiefen

Emotional StampedLock

Die Core Java Packages haben in den letzten Versionen immer mal wieder ein paar Werkzeuge für die Bewältigung von Nebenläufigkeitsproblemen bekommen. Ein neuer Vertreter ist der StampedLock in JDK 8. Grund zur Freude oder Grund für Frust? Wir sehen uns die Sache an.

Sven Ruppert, Heinz Kabutz


Java 8 Tooling in Eclipse

Aus dem Java-EE- und dem Java-SE-Umfeld wissen wir, was es bedeutet, sich mit der Problematik der Nebenläufigkeit auseinander zu setzen. Von akademischer wie praktischer Seite wurden und werden immer wieder verschiedenste Ansätze eingeführt. Gab es früher nur ein Synchronized, kamen später die Semaphoren und Ähnliches dazu. Was also ist das Neue am StampedLock? Wie ist er zu verwenden? Welche Besonderheiten gibt es?

Why Synchronizers?

Zum Einstig nochmals kurz die Fragestellung, warum eigentlich Synchronisationsmittel verwendet werden müssen. Mithilfe der Synchronizers bleiben verteilte mutable Zustände konsistent. Das ist immer dann notwendig, wenn es keine anderen technischen Möglichkeiten gibt, den Zustand des Systems in einer zustandslosen oder rein lokalen, nicht verteilten Version zu realisieren. Zu bedenken ist hier, dass immutable Zustände den Garbage Collector stark beanspruchen können und nicht verteilte/lokale Zustände einen höheren Speicherverbrauch zur Folge haben. Manche unserer Kunden haben HashMaps mit Dateninhalt in der Größenordnung von um die hundert GB.

Coarse-grained Locking

Wie also geht man nun mit der Problematik des Lock­ings um? Eine einfache Methode ist das harte bzw. grobe Locking. Hierbei hat man sicherlich eine Menge Probleme umgangen, jedoch stellt sich auch nicht der gewünschte Erfolg ein. Es wird mehr oder weniger alles seriell abgearbeitet, was zur Folge hat, dass nur ein Core der verfügbaren CPUs mit der Lösung der Aufgabe beschäftigt werden kann. Ziel ist also eine möglichst ausgeglichene Locking-Strategie, die es ermöglicht, möglichst viele Cores gleichzeitig zu verwenden.

„good“ and „bad“ ContextSwitches

Gehen wir also im Folgenden davon aus, dass wir eine erhöhte Auslastung der Cores erreichen. Das bedeutet allerdings auch, dass der jeweilige Kontext für den ­Thread gewechselt werden muss. Man spricht in diesem Zusammenhang vom ContextSwitch. Nun liegt es in der Natur der Sache, dass es gute und schlechte ContextSwitches gibt. Was ist nun der „gute“ und was ist der „schlechte“ ContextSwitch?

Der gute ContextSwitch: Hier sprechen wir von einem Thread, der seine zur Verfügung stehende Rechenzeit voll ausnutzen konnte. Solch ein Thread Context kann normalerweise innerhalb von einem Clock Cycle ein swap out erfahren und ist offiziell unter dem Begriff „Involuntary ContextSwitch“ bekannt. Wir sprechen von einem schlechten ContextSwitch, wenn der Thread stoppen muss, da eine benötigte Ressource...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang