Sichere Veröffentlichung, wenn Werte in synchronisierten Methoden gelesen werden

Question

Meine Frage betrifft sichere Veröffentlichung von Feldwerte in Java (wie hier erläutert Java multi-threading & Safe Publication).

Wie ich es verstehe, kann ein Feld sicher gelesen werden (Zugriff von mehreren Threads Bedeutung wird den richtigen Wert sehen), wenn:

• Lese- und Schreib auf demselben Monitor synchronisiert
• Feld endgültig
• Feld ist flüchtig

Wenn mein Verständnis korrekt die folgende Klasse ist, sollte nicht, da die Thread-sicher sein Der Anfangswert wird ohne diese Merkmale geschrieben. Allerdings kann ich kaum glauben, dass ich firstvolatile machen muss, obwohl nur von einer synchronized Methode zugegriffen wird.

public class Foo { 

    private boolean needsGreeting = true; 

    public synchronized void greet() { 
     if (needsGreeting) { 
      System.out.println("hello"); 
      needsGreeting = false; 
     } 
    } 
} 

Fehle ich etwas? Ist der obige Code korrekt und wenn ja, warum? Oder ist es in solchen Fällen notwendig, firstvolatile oder verwenden Sie eine final AtomicBoolean oder etwas Ähnliches zusätzlich für den Zugriff von einer synchronized Methode.

(Nur um zu klären, ich weiß, dass, wenn der Anfangswert in einem Verfahren synchronized geschrieben wurde, wäre es Thread-sicher auch ohne volatile Schlüsselwort sein.)

Answer 1

Streng genommen, kann ich nicht sehen dass es sicher ist anzunehmen, dass needsGreeting auf wahr gesetzt ist, wenn greet aufgerufen wird.

Damit dies zutrifft, müsste vor der Beziehung zwischen dem ersten Schreiben (das beim Erstellen des Objekts auftritt) und dem ersten Lesen (in der greet -Methode) ein Vorgang stattfinden. Chapter 17 Threads and Locks in dem jedoch JLS, sagt folgende über passiert-vor (hb) Einschränkungen:

17.4.5 Happen-vor Bestellung zwei Aktionen können bestellt werden durch eine geschieht-vor-Beziehung. Wenn eine Handlung stattfindet - vor einer anderen, dann ist die erste sichtbar und bestellt vor der zweiten.

Wenn wir zwei Aktionen x und y haben, schreiben wir hb (x, y), um anzuzeigen, dass x vor y passiert.

• Wenn x und y sind Aktionen aus dem gleichen Faden und x y kommt vor in der Programmreihenfolge, dann hb (x, y).
• Zwischen dem Ende eines Konstruktors eines Objekts und dem Beginn eines Finalizers (§12.6) befindet sich eine "happen-before" -Kante für dieses Objekt.
• Wenn eine Aktion x mit einer folgenden Aktion y synchronisiert wird, haben wir auch hb (x, y).
• Wenn hb (x, y) undhb (y, z), dann hb (x, z).

Darüber hinaus ist die einzige Möglichkeit, ein synchronisierte-mit Bezug auf einzuführen, das heißt, eine Synchronisation um ist etwas, von dem folgenden zu tun:

Synchronisation Aktionen auslösen, die synchronisierte -mit Beziehung zu Aktionen, wie folgt definiert:

• Eine Entsperraktion auf Monitor m synchronisiert mit alle nachfolgenden Sperraktionen auf m (wobei Folge entsprechend der Synchronisationsreihenfolge definiert ist).
• Ein Schreibvorgang in eine flüchtige Variable (§8.3.1.4) v synchronisiert mit allen nachfolgenden Lesevorgängen von v durch einen beliebigen Thread (wobei Folgewert entsprechend der Synchronisationsreihenfolge definiert ist).
• Eine Aktion, die einen Thread startet, wird synchronisiert - mit der ersten Aktion im Thread, die gestartet wird.
• Das Schreiben des Standardwerts (null, false oder null) auf jede Variable wird synchronisiert - mit der ersten Aktion in jedem Thread. Obwohl es etwas seltsam erscheint, einen Standardwert für eine Variable zu schreiben, bevor das Objekt, das die Variable enthält, zugewiesen wird, wird konzeptionell jedes Objekt am Anfang des Programms mit seinen voreingestellten Initialisierungswerten erstellt.
• Die letzte Aktion in einem Thread T1 wird synchronisiert - mit jeder Aktion in einem anderen Thread T2, die erkennt, dass T1 beendet wurde. T2 kann dies durch Aufrufen von T1.isAlive() oder T1.join() erreichen.
• Wenn Thread T1 den Thread T2 unterbricht, wird der Interrupt von T1 synchronisiert - mit jedem Punkt, an dem ein anderer Thread (einschließlich T2) feststellt, dass T2 unterbrochen wurde (durch Auslösen einer InterruptedException oder durch Aufrufen von Thread.interrupted oder Thread.isInterrupted). .

Es sagt nichts, dass „die Konstruktion eines Objekts vor auf dem Objekt keine Aufrufe von Methoden geschieht. Das geschieht-before Beziehung jedoch besagt, dass gibt es einen Fall-before Kante vom Ende eines Konstruktors eines Objekts an den Anfang eines Finalizers (§12.6) für das Objekt, welches kann ein Hinweis darauf sein, dass es nicht eine Vor-Vor-Kante vom Ende eines Konstruktors eines Objekts gibt zum Beginn einer beliebigen Methode!

Answer 2

Zwischen dem Ende eines Konstruktors und Methodenaufrufen gibt es keine "happes Before" -Beziehung. Daher kann ein Thread mit dem Konstruieren der Instanz beginnen und die Referenz verfügbar machen, und ein anderer Thread kann diese Referenz abrufen und mit dem Aufruf der Begrüßung beginnen() Methode auf einem teilweise konstruierten Objekt. Die Synchronisation in Greet() behebt dieses Problem nicht wirklich.

Wenn Sie eine Instanz über das gefeierte, doppelt überprüfte Sperrmuster veröffentlichen, wird es einfacher, das zu sehen. Wenn es eine solche Vor-Zufälligkeits-Beziehung gäbe, hätte es sicher sein sollen, selbst wenn DCLP verwendet wird.

public class Foo { 
    private boolean needsGreeting = true; 

    public synchronized void greet() { 
     if (needsGreeting) { 
      System.out.println("Hello."); 
      needsGreeting = false; 
     } 
    } 
} 

class FooUser { 
    private static Foo foo; 

    public static Foo getFoo() { 
     if (foo == null) { 
      synchronized (FooUser.class) { 
       if (foo == null) { 
        foo = new Foo(); 
       } 
      } 
     } 
     return foo; 
    } 
} 

Wenn mehrere Threads FooUser.getFoo() aufrufen.greet() zur gleichen Zeit, könnte ein Thread die Foo-Instanz konstruieren, aber ein anderer Thread könnte eine Foo-Referenz nicht null finden und greet() aufrufen und findsGeeting ist immer noch falsch.

Ein Beispiel dafür wird in Java Concurrency in Practice (3.5) erwähnt.