Java gleichzeitiger Zugriff auf Feld, Trick nicht flüchtig zu verwenden

Question

Vorwort: Ich weiß, dass in den meisten Fällen mit einem volatilen Feld keine messbare Leistungseinbußen, aber diese Frage ist mehr theoretisch und zielgerichtet auf ein Design mit einem extrem hohe currency-Unterstützung.

Ich habe ein Feld, das eine List<Something> ist, die nach der Erstellung gefüllt wird. Um etwas Leistung zu sparen, möchte ich die Liste in eine schreibgeschützte Map umwandeln. Wenn Sie dies zu einem beliebigen Zeitpunkt tun möchten, benötigen Sie mindestens ein flüchtiges Map-Feld, damit Änderungen für alle Threads sichtbar werden.

Ich dachte an den folgenden Aktionen ausführen:

 
Map map; 

public void get(Object key){ 
    if(map==null){ 
     Map temp = new Map(); 
     for(Object value : super.getList()){ 
      temp.put(value.getKey(),value); 
     } 
     map = temp; 
    } 
    return map.get(key); 
} 

Dies könnte mehrere Threads verursacht die Karte selbst erzeugen, wenn sie den get-Block in einer serialisierten Weise eingeben. Dies wäre kein großes Problem, wenn Threads auf verschiedenen identischen Instanzen der Map arbeiten. Was mich mehr beunruhigt ist:

Ist es möglich, dass ein Thread die neue temporäre Karte dem Kartenfeld zuweist, und dann ein zweiter Thread sieht map!=null und daher Zugriff auf das Kartenfeld, ohne eine neue, aber zu meiner Überraschung stellt fest, dass die Karte leer ist, weil die Put-Operationen noch nicht in einen gemeinsamen Speicherbereich verschoben wurden?

Antworten auf Kommentare:

• Die Fäden die temporäre Karte nach nur ändern, dass es nur gelesen wird.
• Ich muss eine Liste in eine Karte umwandeln wegen einer speziellen JAXB-Konfiguration, die es nicht möglich macht, eine Karte zu erstellen.

Answer 1

Ist es möglich, dass ein Thread die neue temporäre Karte auf die Karte Feld zuweist, und dann ein zweites Gewinde sieht, dass map!=null und damit das Kartenfeld zuzugreift, ohne einen neuen zu erzeugen, aber zu meiner Überraschung fest, dass die Karte ist leer, weil die put-Operationen noch nicht in einen gemeinsamen Speicherbereich verschoben wurden?

Ja, das ist absolut möglich; Zum Beispiel könnte ein optimierender Compiler tatsächlich die lokale temp Variable loswerden und nur das map Feld die ganze Zeit verwenden, vorausgesetzt es map zu null im Falle einer Ausnahme wiederhergestellt.

In ähnlicher Weise könnte ein Thread auch eine nicht leere, nicht leere map anzeigen, die dennoch nicht vollständig ausgefüllt ist. Und wenn Ihre Klasse Map nicht sorgfältig entworfen wurde, um gleichzeitige Lese- und Schreibvorgänge zuzulassen (oder synchronized verwendet, um das Problem zu vermeiden), können Sie auch bizarres Verhalten erhalten, wenn ein Thread seine get-Methode aufruft, während ein anderer seine put aufruft.

Answer 2

Können Sie Ihre Karte im ctor erstellen und als final deklarieren? Vorausgesetzt, Sie verlieren die Karte nicht, so dass andere sie ändern können, sollte dies ausreichen, um Ihre get() sicher durch mehrere Threads gemeinsam nutzbar zu machen.

Answer 3

Wenn Sie wirklich Zweifel haben, ob ein anderer Thread eine "halb fertig" Karte lesen könnte (glaube ich nicht, aber sagen Sie nie nie ;-), können Sie dies versuchen.

Karte ist null oder vollständige

static class MyMap extends HashMap { 
    MyMap (List pList) { 
    for(Object value : pList){ 
     put(value.getKey(), value); 
    } 
    } 
} 

MyMap map; 

public Object get(Object key){ 
    if(map==null){ 
     map = new MyMap (super.getList()); 
    } 
    return map.get(key); 
} 

Oder jemand ein neues eingeführtes Problem nicht sehen?

Answer 4

Zusätzlich zu den oben genannten Sichtbarkeitsproblemen gibt es ein weiteres Problem mit dem ursprünglichen Code, nämlich. es kann hier eine Nullpointer werfen:

return this.map.get(key) 

Welche kontraintuitiv ist, aber das ist, was man von falsch synchronisierten Code erwarten.

Beispielcode, dies zu verhindern:

Map temp; 
if ((temp = this.map) == null) 
{ 

    temp = new ImmutableMap(getList()); 
    this.map = temp; 
} 
return temp.get(key);