¿Las variables volátiles de Java imponen una relación de pasar antes de que se lea?

Question

que tienen una porción de código que se parece a esto:

_{Fragmento A:}

class Creature { 
    private static long numCreated; 
    public Creature() { 
     synchronized (Creature.class) { 
      numCreated++; 
     } 
    } 
    public static long numCreated() { 
     return numCreated; 
    } 
} 

Desde mi entender, ya que la lectura de numCreated no está sincronizado, si Rosca-A crea un Creature a la 1 pm , y el hilo B lee numCreated() a las 2 p.m., numCreated() bien puede haber devuelto 0 o 1 (incluso cuando el hilo-A ha terminado de inicializar el objeto a las 1.05 p.m.).

por lo que añade synchronized a numCreated():

_{fragmento B}:

class Creature { 
    private static long numCreated; 
    public Creature() { 
     synchronized (Creature.class) { 
      numCreated++; 
     } 
    } 
    public static synchronized long numCreated() { // add "synchronized" 
     return numCreated; 
    } 
} 

y todo está bien, excepto que yo estaba pensando, si modifico a Fragmento C, es la variable numCreated ¿Todavía está sincronizado correctamente?

_{Fragmento C:}

class Creature { 
    private static volatile long numCreated; // add "volatile" 
    public Creature() { 
     synchronized (Creature.class) { 
      numCreated++; 
     } 
    } 
    public static long numCreated() { // remove "synchronized" 
     return numCreated; 
    } 
} 

Con Fragmento C, es que garantiza que tan pronto como hilo-A completa la creación de objetos a las 1:05 de la tarde, el llamado del Thread-B a numCreated() es seguro para volver 1?

_{PS: Tengo entendido que en una situación real que probablemente utilice un AtomicLong pero esto es con fines de aprendizaje}

Answer 1

Ver http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility:

una escritura en un campo volátil sucede-antes de cada lectura posterior de ese mismo campo. Las escrituras y lecturas de campos volátiles tienen efectos de coherencia de memoria similares a los de como entrar y salir de monitores, pero no implican el bloqueo de exclusión mutua.

Así que la respuesta es sí. La escritura del volátil en el constructor ocurre antes de la lectura del volátil en numCreated(). Y dado que el incremento no atómico aún se realiza en un bloque sincronizado, la sincronización es correcta (el incremento no es atómico, pero la escritura de la longitud volátil es).