java - una - ¿Los métodos estáticos no sincronizados son seguros si no modifican las variables de clase estáticas?

restricción de java al usar atributos y métodos estáticos.

Question

Me preguntaba si tiene un método estático que no está sincronizado, pero no modifica ninguna variable estática ¿es seguro para subprocesos? ¿Qué pasa si el método crea variables locales dentro de él? Por ejemplo, ¿el siguiente código es seguro para la ejecución de subprocesos?

public static String[] makeStringArray( String a, String b ){
    return new String[]{ a, b };
}

Entonces, si tengo dos hilos que invocan este método de manera continua y simultánea, uno con perros (por ejemplo, "great dane" y "bull dog") y el otro con gatos (digamos "persa" y "siamés") recibiré gatos y perros. en el mismo conjunto? ¿O los gatos y los perros nunca estarán dentro de la misma invocación del método al mismo tiempo?

Answer 1

Este método es 100% seguro para hilos, lo sería incluso si no fuera static . El problema con la seguridad de hilos surge cuando necesita compartir datos entre hilos: debe cuidar la atomicidad, la visibilidad, etc.

Este método solo opera en parámetros, que residen en la pila y referencias a objetos inmutables en el montón. Stack es intrínsecamente local al hilo , por lo que no se produce ningún intercambio de datos.

Los objetos inmutables ( String en este caso) también son seguros para subprocesos porque una vez creados no se pueden cambiar y todos los subprocesos ven el mismo valor. Por otro lado, si el método estaba aceptando (mutable) Date , podría haber tenido un problema. Dos hilos pueden modificar simultáneamente la misma instancia de objeto, causando condiciones de carrera y problemas de visibilidad.

Answer 2

La función es perfectamente segura para hilos.

Si lo piensas ... asume que pasaría si esto fuera diferente. Todas las funciones habituales tendrían problemas de subprocesamiento si no están sincronizadas, por lo que todas las funciones de la API en el JDK tendrían que estar sincronizadas, ya que podrían ser llamadas por varios subprocesos. Y dado que la mayoría de las veces la aplicación usa alguna API, las aplicaciones multiproceso serían efectivamente imposibles.

Esto es demasiado ridículo para pensarlo, así que solo para usted: los métodos no son seguros si hay una razón clara por la cual podría haber problemas. Trate siempre de pensar qué pasa si hay múltiples hilos en mi función, y qué pasa si tiene un depurador de pasos y avanza un paso tras otro el primero ... luego el segundo hilo ... tal vez el segundo otra vez ... ¿Habría problemas? Si encuentra uno, no es seguro para subprocesos.

Tenga en cuenta que la mayoría de las clases de la Colección Java 1.5 no son seguras en cuanto a los hilos, a excepción de las indicadas, como ConcurrentHashMap.

Y si realmente quiere sumergirse en esto, eche un vistazo de cerca a la palabra clave volátil y TODOS sus efectos secundarios. Eche un vistazo a la clase Semaphore () y Lock (), y a sus amigos en java.util.Concurrent. Lee todos los documentos API de las clases. Vale la pena aprender y satisfacer, también.

Perdón por esta respuesta demasiado elaborada.

Answer 3

Los objetos de cadena que son inmutables son otra razón para el escenario de seguridad de subprocesos anterior. En cambio, si se usan objetos mutables (digamos makeMutableArray ...) entonces seguramente se romperá la seguridad del hilo.

Answer 4

Un método solo puede ser inseguro en el subproceso cuando cambia algún estado compartido. Si es estático o no es irrelevante.

Answer 5

Use la palabra clave static con métodos estáticos sincronizados para modificar los datos estáticos compartidos entre los hilos. Con la palabra clave static todos los hilos creados contendrán por una única versión del método.

Utilizar la palabra clave volatile junto con los métodos de instancia sincronizados garantizará que cada subproceso tenga su propia copia de los datos compartidos y que no se filtren las lecturas / escrituras entre subprocesos.