En Java, ¿los métodos que no usan variables estáticas o de clase deben sincronizarse?

Question

¿Los métodos que solo usan variables locales sufren problemas de subprocesamiento? En alguna parte se mencionó que el método con variables locales se copia a cada marco de la pila de hilos para trabajar y no necesita sincronizarse para la implementación de subprocesos múltiples a menos que use referencias/variables de nivel de clase o estáticas.

Answer 1

Si su método solo opera en parámetros y variables definidas localmente (en lugar de miembros de clase), entonces hay problemas de sincronización de los que preocuparse.

Pero ...

Esto significa que cualquier tipos referencia mutables que utiliza imprescindible vivir y morir solamente dentro del ámbito de su método. (Tipos de referencia inmutables no son un problema aquí.) Por ejemplo, esto no es ningún problema:

int doSomething(int myParameter) 
{ 
    MyObject working_set = new MyObject(); 
    interim = working_set.doSomethingElse(myParameter); 
    return working_set.doSomethingElseAgain(interim); 
} 

Se crea una instancia MyObject dentro de su método, hace todo su trabajo en su método y es tos con sangre, a la espera para ser seleccionado por el GC cuando salgas de tu método.

Este, por el contrario, puede ser un problema:

int doSomething(int myParameter) 
{ 
    MyObject working_set = new MyObject(); 
    interim = working_set.doSomethingElse(myParameter); 
    another_interim = doSomethingSneaky(working_set); 
    return working_set.doSomethingElseAgain(another_interim); 
} 

A menos que sepa a ciencia cierta lo que está pasando en doSomethingSneaky(), que pueden tener una necesidad de sincronización en alguna parte. Específicamente puede que tenga que hacer la sincronización en las operaciones en working_set porque doSomethingSneaky() podría almacenar la referencia a su objeto local working_set y pasarlo a otro hilo mientras todavía está haciendo cosas en su método o en los métodos working_set. Aquí deberás estar más a la defensiva.

Si, por supuesto, solo está trabajando con tipos primitivos, incluso llamar a otros métodos, pasar esos valores, no será un problema.

Answer 2

No necesita preocuparse por las variables locales. Sin embargo, las variables de instancia son algo de lo que preocuparse.

Answer 3

¿Los métodos que solo usan variables locales adentro, no sufren problemas de subprocesamiento?

cierto en un sentido muy simplista, pero le permite ser claro - Creo que esto sólo es cierto si:

• tal método utiliza sólo las variables locales que son primitivos o referencias a instancias mutables que no pueden de lo contrario, se accederá fuera del método por cualquier otro medio.

• Este método invoca solo métodos que son seguros para la ejecución de subprocesos.

Algunas maneras estas normas podrían ser violados:

• Una variable local se pudo inicializar para apuntar a un objeto que también es accesible fuera del método. Por ejemplo, una variable local podría apuntar a un singleton (Foo bar = Foo.getSingleton()).

• Una instancia local mantenida por una variable local podría "perder" si la instancia se pasa como un argumento a un método externo que mantiene una referencia a la instancia.

• Una clase sin variables de instancia y con un solo método sin variables locales aún podría llamar al método estático de otra clase que no es segura para subprocesos.

Answer 4

La pregunta es muy genérica, por lo que no espere ninguna especificidad de mi respuesta.

1_ Tenemos que tener más cuidado con los métodos estáticos que decir los métodos de instancia.

2_ @Justmycorrectopinion está sobre la derecha, pero algunos de los términos que se describe tiene que ser más elaborado que ser perfecto. (Incluso si el método estático, sólo funciona en la variable local, todavía hay posibilidad de condición de carrera.)

3_ Para mí hay reglas simples que me han ayudado a analizar la seguridad hilo.

entender si cada uno de los componentes encapsulados dentro de él se puede compartir o no. Entonces la solución más simple es reducir el alcance de todas las variables y solo aumentar el alcance si es absolutamente necesario y si el componente realiza una mutación en un objeto, generalmente no es seguro para subprocesos.

4_ Uso soporte de herramientas para llevar a cabo análisis de código estático en la seguridad hilo. (Idea tiene el complemento checkthread).

5_ Nunca utilice el método estático para realizar la mutación del objeto. Si la invocación de la variable estática causa la mutación del objeto, entonces el desarrollador solo está eludiendo el OOPS.

6_ Siempre documente la seguridad del hilo. Recuerde que es posible que no sea necesario sincronizar algún método cuando se desarrolla, pero se puede hacer que no sea seguro para subprocesos con mucha facilidad.

7_ Por último, pero probablemente mi punto más importante, asegúrese de que la mayor parte de sus objetos son inmutables. En mi experiencia, la mayoría de las veces, nunca tuve que hacer mutables muchos de mis objetos. (En raros casos en que el estado del objeto que hay que cambiar, copiar defensiva Nueva Creación/Objeto es casi siempre mejor.)