¿Por qué una variable de miembro Object no puede ser definitiva y volátil en Java?

Question

Si en una clase tengo una instancia ConcurrentHashMap que será modificado y leído por múltiples hilos que podría definir así:

public class My Class { 

    private volatile ConcurrentHashMap<String,String> myMap = new ConcurrentHashMap<String,String>(); 
... 
} 

añadiendo final a los resultados de campo myMap en un error que dice que sólo puedo utilizar final o volátil. ¿Por qué no puede ser ambos?

Answer 1

volatile solo tiene relevancia para las modificaciones de la variable en sí, no el objeto al que se refiere. No tiene sentido tener un campo final volatile porque los campos finales no se pueden modificar. Simplemente declare el campo final y debería estar bien.

Answer 2

volatile se utiliza para las variables que su valor puede cambiar, en ciertos casos, de lo contrario no hay necesidad de volatile, y final significa que la variable no puede cambiar, así que no hay necesidad de volatile.

Sus preocupaciones de concurrencia son importantes, pero haciendo que el HashMapvolátil no va a resolver el problema, para el manejo de los problemas de concurrencia, ya utiliza ConcurrentHashMap.

Answer 3

Debido volatile y final son dos extremos en Java

volatile significa que la variable está ligada a los cambios

final: el valor de la variable nunca va a cambiar en absoluto

Answer 4

Debido a que no lo hace ningún sentido. La volatilidad afecta el valor de referencia del objeto, no los campos del objeto/etc.

En su situación (tiene un mapa concurrente) debe hacer el campo final.

Answer 5

volatile modificador garantiza que todas las lecturas y escrituras Vaya estrecho a la memoria principal, es decir, al igual que la variable de acceso es casi en synchronized bloque. Esto es irrelevante para la variable final que no se puede cambiar.

Answer 6

Es a causa del Modelo de Memoria Java (JMM).

Básicamente, cuando declara el campo de objeto como final, necesita inicializarlo en el constructor del objeto y luego el campo final no cambiará su valor. Y JMM promete que después de que ctor finalice, cualquier subproceso verá el mismo valor (correcto) del campo final. Por lo tanto, no necesitará utilizar la sincronización explícita, como synchronize o Lock para permitir que todos los hilos vean el valor correcto del campo final.

Cuando declara el campo del objeto como volatile, el valor del campo puede cambiar, pero aún así cada lectura del valor de cualquier subproceso verá el último valor escrito en él.

Así, final y volatile logran el mismo propósito: la visibilidad del valor del campo del objeto, pero primero se usa específicamente para que una variable solo se pueda asignar una vez y la segunda se use para una variable que se puede cambiar muchas veces.

Referencias:

• http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4

• http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4

Answer 7

Un campo volatile le da garantías como lo que sucede cuando se cambie. (No hay un objeto que podría ser una referencia a)

Un campo final no se puede cambiar (Lo que hacen referencia a los campos puede ser cambiado)

No tiene sentido tener ambos.