¿Volátil o sincronizado para el tipo primitivo?

Question

En Java, la asignación es atómica si el tamaño de la variable es menor o igual a 32 bits, pero no si es más de 32 bits.

¿Qué (volátil/sincronizado) sería más eficiente de usar en caso de asignación doble o larga?

igual,

volatile double x = y; 

sincronizada no es aplicable con el argumento primitivo. ¿Cómo uso sincronizado en este caso? Por supuesto, no quiero bloquear mi clase, por lo que this no se debe utilizar.

Answer 1

Si encuentra que el bloqueo en el objeto mismo es demasiado pesado, entonces sincronizado es el camino a seguir. Antes de Java 1.5 Volatile puede haber sido una buena opción, pero ahora volátil puede tener un gran impacto forzando la ordenación de instrucciones en el método donde ocurre la asignación. Cree un objeto por separado (private final Object X_LOCK = new Object();) y sincronícelo cuando configure u obtenga el valor de ese doble. Esto le dará un buen nivel de control sobre el bloqueo, que parece que necesita.

En el nuevo paquete de simultaneidad hay más opciones, como AtomicReference, que puede ser un buen sustituto de la volatilidad si realmente necesita evitar la sincronización.

Answer 2

¿Qué estás tratando de hacer? Las palabras clave synchronized y volatile son mecanismos en Java que se pueden usar para garantizar que los diferentes hilos que observan los mismos valores observen valores consistentes. En particular, le permiten razonar acerca de sucede antes de las relaciones en sus programas.

Simplemente no puede evitar el uso de uno de volatile o synchronized para acceder correctamente a los campos no final en un programa multiproceso. Dicho esto, la razón principal por la que es probable que requiera synchronized sobre volatile es el requisito para usar operaciones de comparación atómica y establecer (es decir, no será ninguna consideración de rendimiento). Por ejemplo, en un multi-hilo programa:

volatile int i = 0; 

public void foo() { 
    if (i == 0) i = i + 1; 
} 

El código anterior es inherentemente insegura, a pesar de la declaración de la variable como medios volátiles que lee y escribe se vuelcan a la memoria principal - la única aplicación segura de tal El método sería algo así como:

int i = 0; 

public synchronized void foo() { 
    if (i == 0) i = i + 1; 
} 

¿Cuál debería preferir? Bueno, si tiene varios hilos que modifican un campo que depende del valor de ese campo (es decir, comparar y establecer), entonces synchronized es la única solución segura.

También vale la pena decir: la sobrecarga de rendimiento de synchronized no es un problema (en la gran mayoría de los casos). Los problemas de sincronización de rendimiento generalmente se deben a cuellos de botella innecesarios, bloqueos o bloqueos y se pueden mitigar si es necesario. Cualquier puros reloj ciclos sobrecarga será eclipsada por otras cosas que la aplicación hace: archivo IO, consultas de bases de datos, etc. interacción remota

Answer 3

KDSRathore, puede utilizar algunos bloqueos explícitos, o hacer algún objeto objeto ficticio = new Object (), en el cual se sincroniza en setter/getter de ese doble

Answer 4

volátil es sin duda el camino a seguir si solo está haciendo una tarea. Estoy seguro de que lo sabes, pero desde que surgió: si quieres hacer operaciones más complejas (incrementar el valor, por ejemplo) necesitarías sincronizar. i ++ nunca es seguro para ningún tipo de variable. Necesitas sincronizar. i ++ y similares, ya que en realidad es más de 1 operación.

No

: Se expresó que usted podría utilizar AtomicDouble pero actualmente no existe una AtomicDouble en java.util.concurrent.atomic

Si usted está haciendo un múltiples operaciones en X, que requiere ajustarlo a un nuevo valor al final, es posible hacerlo de una manera segura para hilos sin ningún tipo de bloqueo, y que sea seguro para hilos, usando compare y set. Ejemplo:

AtomicLong x = new AtomicLong(SomeValue); 
public void doStuff() { 
    double oldX; 
    double newX; 
    do { 
    oldX = x.get(); 
    newX = calculateNewX(oldX); 
    } while (!x.compareAndSet 
     (Double.doubleToLongBits(oldX), Double.doubleToLongBits(newX))); 

Esto funciona porque compareAndSet verá si el valor de x ha cambiado desde la última vez que lo lea. Si x ha cambiado, entonces está obligado a hacer el cálculo nuevamente y volver a intentar configurarlo.

Por supuesto, podría implementar su propio AtomicDouble en lugar de hacer estas conversiones de doubleToLongBits. Eche un vistazo a AtomicFieldUpdater.

Answer 5

Según the oracle documentation, puede utilizar volátil para referirse al doble objetivo:

volatile Double x = y; 

"escribe y lee las referencias son siempre atómica, independientemente de si se implementan como de 32 bits o de 64 valores de bit ".