2012-03-03 35 views
10

Tengo una pregunta sobre la invocación de métodos de subprocesos múltiples en Java. Digamos que tenemos un objeto único, y su clase declara como sigue:Invocación simultánea del método Java del objeto singleton

public class SomeClass { 
    public void someMethod(SomeValueObject object) { 

     if (object.condition1) { 
      ... 
     } 
     if (object.condition2) { 
      ... 
     } 
     if (object.condition3) { 
      ... 
     } 

    } 
} 

Me pregunto si este objeto Singleton está siendo simultáneamente acceder y su algunMetodo llama con distintas instancias SomeValueObject, existe la posibilidad de un hilo al azar cambiar la referencia de objeto para la invocación de método de otro hilo y desordenar las cosas? ¿Y qué hay de los campos creados dentro del alcance del método? Lo que no conozco, ¿se crea un contexto de Método separado para cada hilo que invoca el método o el contexto del Método es el mismo para todos los hilos que lo invocan? Si es el último caso, creo que necesito la palabra clave sincronizada para seguridad de subprocesos o uso instancias distintas de SomeClass para cada subproceso (en caso de que necesite una ejecución más rápida sobre la optimización de memoria). ¿Podría explicarme el asunto por favor?

P.S. Gracias por todas sus respuestas chicos!

Respuesta

13

Si todo es local, su método es seguro para subprocesos como es. Cada hilo tendrá su propio argumento de objeto en la pila, y no interferirán entre sí.

Puede haber problemas de concurrencia si dos subprocesos invocan este método con el mismo objeto como argumento, o si dos de esos objetos comparten algún estado, pero ese no es el problema del singleton. Es el problema del estado compartido, que debe estar correctamente sincronizado.

Buena regla de oro: un objeto sin estado es seguro para subprocesos. Un objeto con estado inmutable es seguro para subprocesos. Un objeto con estado mutable no es seguro para subprocesos si no sincroniza correctamente el acceso al estado compartido.

8

No, los subprocesos no podrán cambiar las variables locales de un subproceso diferente.

Todas las variables creadas en el alcance del método [variables locales], incluidos los parámetros, se asignan en la pila del hilo específico y, por lo tanto, no se comparten entre dos hilos.

Sin embargo, los campos de todas las clases no son seguros, y si un hilo los cambia, se reflejarán en todos.

3

Cada hilo tiene su propia pila de ejecución. Esta área de memoria contiene todas las variables locales y parámetros de método. Cuando dos hilos ejecutan el mismo código al mismo tiempo, ambos usan pilas distintas.

Por lo tanto, no es posible cambiar el valor de un parámetro de método o variable local por un hilo diferente.

2

Un método es esencialmente una pieza de código. Cuando un grupo de hilos llama a un método, existe una copia distinta del método en la pila de cada hilo, por lo que las variables locales no interfieren entre sí.

Si, además, todos los parámetros son distintos para cada subproceso, entonces existe un aislamiento perfecto, a menos que su método esté funcionando en datos compartidos adicionales dentro de su código.

3

Lo que dijeron los demás. Aunque para nit-pick: en java, solo las variables primitivas locales y los parámetros (int, long, boolean, etc.) se asignan en la pila, todos los demás objetos se asignan en el montón y solo las referencias se almacenan en la pila. Pero los otros dijeron que cada invocación del método verá su propia copia de las variables locales.

Tenga en cuenta que los objetos (a diferencia de primitivos) pasados ​​como parámetros no son necesariamente únicos para cada invocación, ya que los parámetros de objeto son solo referencias. Entonces, si pasa el mismo objeto de entrada al método dos veces, ambos operarán en la misma entrada.

Cuestiones relacionadas