Vor der JSR 133-Spezifikation (Java 5) hatte das Java Memory Model keine formalen Happens-Before-Regeln, was harmlose Datenrennen gefährlich machte. String war immer eine performancekritische unveränderliche Klasse, die intensiv in HashMap-Operationen genutzt wurde. Frühere JDK-Versionen führten ein verzögertes Hash-Caching ein, um zu vermeiden, dass der Hash für große Strings wiederholt neu berechnet wird. Die Entscheidung, auf das hash-Feld volatile zu verzichten, war eine bewusste Optimierung, die vor modernen Synchronisationsprimitive getroffen wurde, und basierte auf der idempotenten Natur der Berechnung sowie spezifischen Atomicitätsgarantien, die im JLS in Java 5 hinzugefügt wurden.
Wenn mehrere Threads gleichzeitig hashCode() auf einem neu erstellten String aufrufen, können sie alle den Standardwert 0 im hash-Feld beobachten. Ohne Synchronisierung entsteht ein Datenrennen, bei dem mehrere Threads gleichzeitig den Hashwert berechnen und versuchen könnten, ihn zurückzuschreiben. Die Herausforderung besteht darin, sicherzustellen, dass kein Thread jemals einen teilweise geschriebenen (zerrissenen) Hashwert oder einen inkonsistenten Zustand sieht, während die prohibierenden Kosten von Speicherbarrieren vermieden werden, die mit volatile Lese- und Schreibvorgängen bei jedem Aufruf von hashCode() verbunden sind.
Die Lösung beruht auf zwei grundlegenden JMM-Eigenschaften. Erstens garantiert die Java Language Specification (§17.7), dass Schreibvorgänge auf 32-Bit-Primitiven (int) atomar sind, was Wortzerreißen verhindert. Zweitens etabliert der String-Konstruktor eine Happens-Before-Beziehung durch sein final value-Feld, das sicherstellt, dass das zugrunde liegende Array für jeden Thread, der die Referenz erhält, vollständig sichtbar ist. Da die Hashberechnung eine reine Funktion dieser unveränderlichen, sicher veröffentlichten Daten ist, ist das Rennen um die Auffüllung des Caches harmlos. Wenn ein Thread einen veralteten 0-Wert liest, berechnet er einfach den identischen Wert erneut; wenn er den zwischengespeicherten Wert liest, verwendet er ihn. Der atomare Schreibvorgang stellt sicher, dass der Wert entweder vollständig beobachtet oder gar nicht beobachtet wird, niemals beschädigt.
public int hashCode() { int h = hash; // Nicht-volatile Lesevorgang: kann 0 oder zwischengespeicherten Wert sehen if (h == 0 && value.length > 0) { char val[] = value; for (int i = 0; i < value.length; i++) { h = 31 * h + val[i]; } hash = h; // Atomarer Schreibvorgang: 32-Bit-Zuweisung ist unteilbar } return h; }
Wir entwarfen einen Hochdurchsatz-Übertragungsdienst, der Millionen von CSV-Datensätzen pro Sekunde verarbeitete. Jeder Datensatz generierte mehrere String-Schlüssel für einen ConcurrentHashMap-Cache. Profiling ergab, dass die Berechnungen von hashCode() 15 % der CPU-Zeit durch große String-Schlüssel in Anspruch nahmen.
Lösung A: volatile hash-Feld. Wir zogen in Betracht, volatile zum hash-Feld in einer benutzerdefinierten String-Hülle hinzuzufügen. Die Vorteile umfassten sofortige Sichtbarkeit über alle Kerne hinweg und strikte sequentielle Konsistenz. Die Nachteile waren jedoch schwerwiegend: JMH-Benchmarks zeigten einen Rückgang der Durchsatzleistung um 400 % aufgrund des Speicherzuverlässigkeitsverkehrs und der Kosten von Speicherbarrieren bei jeder Kartenoperation.
Lösung B: synchronisierte hashCode(). Wir testeten die Synchronisierung der Berechnung. Die Vorteile waren Einfachheit und absolute Korrektheit. Die Nachteile waren katastrophale Contention; unter 32 Threads schoss die Latenz von 2 Nanosekunden auf 800 Nanosekunden pro Operation in die Höhe, während Threads auf den Monitor warteten.
Lösung C: Harmloses Rennen (aktuelle Implementierung). Wir behielten das unsynchronisierte, idempotente Caching bei. Die Vorteile waren null Synchronisationsüberhead und perfekte Skalierbarkeit mit der Anzahl der Kerne. Die Nachteile waren theoretischer Natur: gelegentliche redundante Berechnungen, wenn Threads während des ersten Zugriffs um die Vorherrschaft rangen. Wir wählten Lösung C, weil die Kosten für die Neuberechnung eines Hashs (Cache-Miss) im Vergleich zu den Kosten von Speicherzuverlässigkeitsprotokollen (volatile) oder Contention (synchronized) vernachlässigbar waren.
Ergebnis: Das System hielt 2,5 Millionen Operationen pro Sekunde und Kern aufrecht, ohne dass hashCode() in den Top 100 der begehrtesten Methoden erschien, was bestätigte, dass das harmlose Datenrennen der richtige architektonische Kompromiss für diese unveränderliche Datenstruktur war.
Warum verletzt das Fehlen von volatile nicht die Happens-Before-Beziehung zwischen dem Thread, der den String erstellt, und dem Thread, der seinen Hash berechnet?
Die Happens-Before-Beziehung wird tatsächlich durch die sichere Veröffentlichung des String-Objekts selbst hergestellt, nicht durch das Hashfeld. Wenn ein String konstruierte wird, garantiert sein final value-Feld, dass die Inhalte des zugrunde liegenden Arrays für jeden Thread, der die Referenz erhält, sichtbar sind. Das hash-Feld ist lediglich ein Cache; das Beobachten seines Standardwerts 0 ist ein gültiger Programmzustand, der einfach die Berechnung auslöst. Das JMM stellt sicher, dass das unveränderliche value-Array konsistent ist, und da der Hash rein aus diesen sichtbaren Daten abgeleitet wird, liefert die Berechnung dasselbe Ergebnis, unabhängig davon, welcher Thread sie ausführt.
Kann diese gleiche Optimierung auf einen 64-Bit langen Hashwert ohne Verwendung von volatile angewendet werden?
Nein. Das JMM garantiert nur Atomizität für 32-Bit-Primitiven (int, float) auf allen Architekturen. Für 64-Bit-Primitiven (long, double) erlaubt die Spezifikation das Wortzerreißen auf 32-Bit-JVMs oder bestimmten Architekturen ohne volatile oder Synchronisierung. Ein Thread könnte theoretisch die oberen 32 Bit eines berechneten Hashs und die unteren 32 Bit eines anderen beobachten, was zu einem völlig falschen, nicht nullen Hashwert führen würde, der die Platzierung von HashMap-Buckets beschädigen könnte. Daher erfordert das Caching von 64-Bit-Hashes volatile oder AtomicLong.
Wie unterscheidet sich dies von dem fehlerhaften "Double-Checked Locking"- idiom für Singleton-Initialisierung?
Der entscheidende Unterschied liegt in sicherer Veröffentlichung und Idempotenz. Bei fehlerhaftem Double-Checked Locking besteht das Problem darin, eine nicht-null Referenz auf ein Objekt zu beobachten, dessen Konstruktor nicht abgeschlossen ist (Umordnung der Referenzzuweisung im Vergleich zur Ausführung des Konstruktors). In String.hashCode() ist das String-Objekt bereits sicher veröffentlicht und vollständig konstruiert; das hash-Feld ist lediglich ein faul initialisierter Cache von reinem Datum. Das Sehen von 0 (nicht initialisiert) ist kein partieller Konstruktionsprozess, sondern ein gültiger Anfangszustand. Darüber hinaus ist die Operation idempotent – mehrere Threads, die denselben berechneten Wert schreiben, produzieren dasselbe Ergebnis wie ein Thread, während DCL genau eine Instanzenerstellung erfordert.