tipos sirve referencia que para locales las globales ejemplos declarar clase ambito java thread-safety

sirve - Por qué las variables locales son seguras en Java



variables de referencia en java (7)

Estaba leyendo multi-threading en Java y me encontré con esto

Las variables locales son seguras para subprocesos en Java.

Desde entonces he estado pensando cómo / por qué las variables locales son seguras para hilos.

¿Puede alguien por favor hágamelo saber?


Además de las otras respuestas como Nambari''s.

Me gustaría señalar que puedes usar una variable local en un método tipo anónimo:

Este método podría ser llamado en otros hilos que podrían comprometer la seguridad del hilo, por lo que java obliga a todas las variables locales utilizadas en los tipos anónimos a declararse como definitivas.

Considera este código ilegal:

public void nonCompilableMethod() { int i=0; for(int t=0; t<100; t++) { new Thread(new Runnable() { public void run() { i++; //compile error, i must be final: //Cannot refer to a non-final variable i inside an //inner class defined in a different method } }).start(); } }

Si java lo permitió (como C # lo hace a través de "cierres"), una variable local ya no sería segura en todos los casos. En este caso, el valor de i al final de todos los hilos no se garantiza que sea 100 .


Básicamente, hay cuatro tipos de almacenamiento en Java para almacenar información de clase y datos:

Method Area, Heap, JAVA Stack, PC

por lo que el área de Método y el Heap es compartido por todos los hilos, pero cada hilo tiene su propia JAVA Stack y PC y eso no es compartido por ningún otro Threads.

Cada método en java es como marco de pila. por lo tanto, cuando un subproceso llama un método, ese marco de pila se carga en su pila JAVA. Todas las variables locales que están en ese marco de pila y pila de operandos relacionados no son compartidas por otros. La PC tendrá información de la siguiente instrucción para ejecutar en el código de bytes del método. entonces todas las variables locales son THREAD SAFE.

@Weston también ha dado una buena respuesta.


Cada invocación de método tiene sus propias variables locales y, obviamente, una invocación de método ocurre en un solo subproceso. Una variable que solo se actualiza con un único hilo es intrínsecamente segura para subprocesos.

Sin embargo , observe atentamente qué significa exactamente esto: solo las escrituras en la variable en sí son seguras para subprocesos; los métodos de llamada en el objeto al que se refiere no son inherentemente seguros para subprocesos . Lo mismo ocurre con la actualización directa de las variables del objeto.


Cuando creas un hilo, tendrá su propia pila creada. Dos hilos tendrán dos pilas y un hilo nunca comparte su pila con otro hilo.

A todas las variables locales definidas en su programa se les asignará memoria en la pila (como comentó Jatin, memoria aquí significa valor de referencia para objetos y valor para tipos primitivos) (Cada llamada a método por un hilo crea un marco apilado en su propia pila). Tan pronto como la ejecución del método se complete con este hilo, se eliminará el marco de pila.

Hay una gran conferencia del profesor de Stanford en youtube que puede ayudarlo a comprender este concepto.


El hilo tendrá su propia pila. Dos hilos tendrán dos pilas y un hilo nunca comparte su pila con otro hilo. Las variables locales se almacenan en la propia pila de cada hilo. Eso significa que las variables locales nunca se comparten entre hilos.


Las variables locales se almacenan en la propia pila de cada hilo. Eso significa que las variables locales nunca se comparten entre hilos. Eso también significa que todas las variables primitivas locales son seguras para hilos.

public void someMethod(){ long threadSafeInt = 0; threadSafeInt++; }

Las referencias locales a los objetos son un poco diferentes. La referencia en sí no es compartida. El objeto al que se hace referencia, sin embargo, no se almacena en la pila local de cada subproceso. Todos los objetos se almacenan en el montón compartido. Si un objeto creado localmente nunca escapa al método en el que se creó, es seguro para subprocesos. De hecho, también puede pasarlo a otros métodos y objetos, siempre que ninguno de estos métodos u objetos haga que el objeto pasado esté disponible para otros hilos.


Piense en métodos como definiciones de funcionalidad. Cuando dos hilos ejecutan el mismo método, de ninguna manera están relacionados. Cada uno creará su propia versión de cada variable local y no podrá interactuar entre sí de ninguna manera.

Si las variables no son locales (como las variables de instancia definidas fuera de un método en el nivel de clase), entonces se adjuntan a la instancia (no a una sola ejecución del método). En este caso, dos subprocesos que ejecutan el mismo método ambos ven la variable única, y esto no es seguro para subprocesos.

Considere estos dos casos:

public class NotThreadsafe { int x = 0; public int incrementX() { x++; return x; } } public class Threadsafe { public int getTwoTimesTwo() { int x = 1; x++; return x*x; } }

En el primero, dos subprocesos que se ejecutan en la misma instancia de NotThreadsafe verán la misma x. Esto podría ser peligroso, porque los hilos están tratando de cambiar x! En el segundo, dos subprocesos que se ejecutan en la misma instancia de Threadsafe verán variables totalmente diferentes y no pueden afectarse entre sí.