Java: Caching von nicht-volatile-Variablen von verschiedenen threads

In diesem Fall müssen Sie die Verwendung von die sichere Veröffentlichung Idiome, wenn in Ihrem Objekt zur Verfügung, zu anderen threads, nämlich (von Java Concurrency in Practice):

• Der Initialisierung eine Referenz auf ein Objekt von einem statischen Initialisierer;
• Speichern eine Referenz darauf in einen flüchtigen Bereich oder AtomicReference;
• Speichern eine Referenz darauf in einem letzten Feld einer richtig konstruierten Objekt; oder
• Speichern eine Referenz darauf in ein Feld, das ist richtig, bewacht von einem Schloss.

Wenn Sie die sichere Veröffentlichung, Sie brauchen nicht zu erklären, Felder volatile.

Jedoch, wenn Sie es nicht verwenden, deklarieren Felder volatile (theoretisch) nicht helfen, da die memory-Barrieren entstehen durch volatile sind, der auf einer Seite: flüchtige schreiben kann nachbestellt werden, die mit nicht-flüchtigen Aktionen nach.

So, volatile gewährleistet die Korrektheit der folgende Fall:

class Foo {
    public int x;
}
volatile Foo foo;

//Thread 1
Foo f = new Foo();
f.x = 42;
foo = f; //Safe publication via volatile reference

//Thread 2
if (foo != null)
     System.out.println(foo.x); //Guaranteed to see 42

aber nicht in diesem Fall:

class Foo {
    public volatile int x;
}
Foo foo;

//Thread 1
Foo f = new Foo();
//Volatile doesn't prevent reordering of the following actions!!!
f.x = 42;
foo = f;

//Thread 2
if (foo != null)
     System.out.println(foo.x); //NOT guaranteed to see 42, 
                                //since f.x = 42 can happen after foo = f

Aus der theoretischen Sicht, in der ersten Probe gibt es eine transitive passiert-vor der Beziehung

f.x = 42 happens before foo = f happens before read of foo.x 

Im zweiten Beispiel f.x = 42 und Lesen von foo.x sind nicht verbunden durch happens-before Beziehung, deshalb können Sie ausgeführt werden, in beliebiger Reihenfolge.

Um zu verstehen, was Los ist, ich lese über das Java-Memory-Modell (JMM). Eine nützliche Einführung in die JMM können gefunden werden in Java Conurrency in der Praxis.

Ich denke, die Antwort auf die Frage: ja, in dem Beispiel machen die Mitglieder der Objekt volatile ist NICHT notwendig. Aber diese Umsetzung ist eher spröde, wie diese Garantie hängt von der genauen REIHENFOLGE, in der Dinge getan werden und auf die Thread-Sicherheit der Container. Ein builder pattern wäre eine viel bessere option.

Warum ist es garantiert:

1. Der thread 1 nicht alle die Abtretung, BEVOR der Wert in die thread-sichere container.

2. Die add-Methode des thread-sichere container verwenden müssen einige Synchronisations-Konstrukte wie flüchtig Lesen /schreiben, zu sperren oder zu synchronisieren(). Dies garantiert zwei Dinge:

   1. Anweisungen, die in thread 1. vor der Synchronisation wird dann tatsächlich ausgeführt werden, vor. Das ist die JVM ist nicht erlaubt, um neu anordnen, Anweisungen zu Optimierungszwecken mit der Synchronisation Unterricht. Dies wird als geschieht-bevor Garantie.
   2. Alle schreibt, die passieren, bevor die Synchronisation thread 1 wird anschließend sichtbar für alle anderen threads.

3. Die Objekte werden nicht verändert nach der Veröffentlichung.

Jedoch, wenn der container war nicht thread-sicher oder die Ordnung der Dinge verändert wurde und jemand sich nicht bewusst, das Muster oder die Objekte, die versehentlich verändert nach der Veröffentlichung, dann gibt es keine Garantien mehr. So, nach dem Builder-Muster können erzeugt werden, indem google AutoWert oder Freebuilder ist viel sicherer.

In diesem Artikel auf das Thema ist auch ziemlich gut:
http://tutorials.jenkov.com/java-concurrency/volatile.html