¿Por qué este código no es seguro para subprocesos?

Question

En el siguiente fragmento de código, declarar el método doThings() como estático haría que la clase sea segura para subprocesos. ¿Es la razón para esto que si se inician múltiples hilos de TestSeven y dado que x es una variable estática, podría ocurrir una condición de carrera?

public class TestSeven extends Thread{ 

    private static int x; 

    public synchronized void doThings(){ 
     int current = x; 
     current++; 
     x = current; 
    } 

    public void run(){ 
     doThings(); 
    } 

    public static void main(String args[]){ 
     TestSeven t = new TestSeven(); 
     Thread thread = new Thread(t); 
     thread.start(); 
    } 
} 

Answer 1

Sí, exactamente. La naturaleza synchronized de doThings solo impide que varios subprocesos la invoquen simultáneamente en la misma instancia. La variable x se comparte en una base global, no por instancia, por lo tanto no es seguro.

En términos del mundo real, pensar en él como un cuarto de baño con varias puertas - que alguien pueda abrir una puerta y luego bloquearlo, pero eso no impide que otra persona entre en medio de una puerta diferente ...

Answer 2

Creo que si el método no es estático, cada objeto TestSeven se sincronizaría usando su propio bloqueo, por lo que habrá un hilo por bloqueo y ninguno de ellos tendrá que esperar otro hilo. Si el método se declara estático, parece recordar que se bloquea en el objeto Class correspondiente.

Answer 3

Solo para agregar que si declara el método doThings estático, se sincronizará en el bloqueo de clase en lugar del bloqueo de instancia, por lo que será a prueba de balas.

Answer 4

sí. La condición de carrera podría ocurrir en esto. Como está sincronizando el método, no su variable. Entonces, de acuerdo con la definición de la condición de carrera, un hilo leerá el valor de la variable, mientras que otro método sincronizado puede escribirlo. Entonces una condición de carrera estará allí.

Answer 5

Sincroniza su código en this, lo que significa en esa instancia de TestSeven. x es estático, por lo que no se bloqueará. Es por eso que, desde diferentes instancias, puede acceder al mismo x. Para det a lock en ese atributo, necesitarás sincronizar en la clase.