es la sincronización necesaria durante la lectura si hay contención podría ocurrir

Question

Considere francotirador código de abajo:

package sync; 

public class LockQuestion { 
    private String mutable; 

    public synchronized void setMutable(String mutable) { 
     this.mutable = mutable; 
    } 

    public String getMutable() { 
     return mutable; 
    } 
} 

A la hora Time1 hilo Thread1 actualizará la variable ‘mutable’. Se necesita sincronización en setter para vaciar la memoria de la memoria caché local a la memoria principal. En el momento Time2 (Time2> Time1, no hay contención de hilos) thread Thread2 leerá el valor de mutable.

La pregunta es: ¿tengo que poner sincronizado antes de getter? Parece que esto no causará ningún problema: la memoria debe estar actualizada y la memoria caché local de Thread2 debe estar invalidada por Thread1, &, pero no estoy seguro.

Answer 1

En lugar de preguntarse, ¿por qué no utilizar las referencias atómicas en java.util.concurrent?

(y por lo que vale la pena, mi lectura de happens-before no garantiza que Thread2 vea cambios en mutables a menos que también use sincronización ... pero siempre me da dolor de cabeza esa parte de JLS, así que use el atómico referencias)

Answer 2

¿Está absolutamente seguro de que se llamará al captador solo después de que se haya llamado al colocador? Si es así, no necesita que el getter esté sincronizado, ya que las lecturas concurrentes no necesitan sincronizarse.

Si existe la posibilidad de que se puedan invocar get y set al mismo tiempo, definitivamente debe sincronizar los dos.

Answer 3

Será bien si haces detalles mutables volátil, en la "cheap read-write lock"

Answer 4

Esto probablemente nunca dará lugar a un comportamiento incorrecto, pero a menos que también se garantiza el orden en que los hilos de inicio en, no se puede necesariamente garantía que el compilador no reordenó la lectura en Thread2 antes de la escritura en Thread1. Más específicamente, the entire Java runtime only has to guarantee that threads execute as if they were run in serial. Por lo tanto, siempre que el hilo tenga el mismo resultado ejecutándose en serie bajo optimizaciones, toda la pila de idiomas (compilador, hardware, tiempo de ejecución del lenguaje) puede hacer prácticamente todo lo que quiera. Incluyendo permitir que Thread2 guarde en caché el resultado de LockQuestion.getMutable().

En la práctica, me sorprendería mucho si eso ocurriera. Si desea garantizar que esto no ocurra, haga que LockQuestion.mutable se declare como final y se inicialice en el constructor. Or use the following idiom:

private static class LazySomethingHolder { 
    public static Something something = new Something(); 
} 

public static Something getInstance() { 
    return LazySomethingHolder.something; 
} 

Answer 5

Si usted se preocupa tanto por el rendimiento en el hilo de la lectura, a continuación, lo que se hace es leer el valor de una vez usando una correcta sincronización o referencias volátiles o atómicas. Luego asigna el valor a una vieja variable simple.

La asignación a la variable plain se garantiza después de la lectura atómica (porque ¿de qué otro modo podría obtener el valor?) Y si el valor nunca volverá a escribirse en otra cadena, ya está todo configurado.

Answer 6

Creo que deberías comenzar con algo que sea correcto y optimizar luego cuando sabes que tienes un problema. Solo usaría AtomicReference a menos que unos nano segundos sea demasiado largo.;)

public static void main(String... args) { 
    AtomicReference<String> ars = new AtomicReference<String>(); 
    ars.set("hello"); 
    long start = System.nanoTime(); 
    int runs = 1000* 1000 * 1000; 
    int length = test(ars, runs); 
    long time = System.nanoTime() - start; 
    System.out.printf("get() costs " + 1000*time/runs + " ps."); 
} 

private static int test(AtomicReference<String> ars, int runs) { 
    int len = 0; 
    for (int i = 0; i < runs; i++) 
     len = ars.get().length(); 
    return len; 
} 

Prints

get() costs 1219 ps. 

ps es un pico-segundos, con es 1 millonésima parte de un micro-segundo.