¿Cómo hacer que un método sea seguro para subprocesos en Java?

Pregunta de la entrevista:

¿El siguiente método es seguro para subprocesos? ¿Cómo hacerlo seguro para subprocesos?

class MyCounter {
	private static int counter = 0;
 
	public static int getCount() {
		return counter++;
	}
}

Esta publicación explica una pregunta de entrevista general que ha sido formulada por Google y muchas empresas. Es de bajo nivel y no se trata de cómo diseñar un programa concurrente.

En primer lugar, la respuesta es NO. El método no es seguro para subprocesos, porque el contador ++ La operación no es atómica, lo que significa que consta de más de una operación atómica. En este caso, uno accede al valor y el otro aumenta el valor en uno.

Cuando el subproceso 1 accede al método en t1, es posible que el subproceso 2 no se complete con el método. Por tanto, el valor devuelto al hilo 1 es el valor que no se ha aumentado.

Hacer un método seguro para subprocesos – Método 1

Agregar sincronizado a este método lo hará seguro para subprocesos. Cuándo sincronizado se agrega a un método estático, el Clase objeto es el objeto que está bloqueado.

¿Marcarlo está lo suficientemente sincronizado? La respuesta es sí.

class MyCounter {
	private static int counter = 0;
 
	public static synchronized int getCount() {
		return counter++;
	}
}

Si el método no es estático, agregue sincronizado La palabra clave sincronizará la instancia de la clase, no la Clase objeto.

Hacer un método seguro para subprocesos – Método 2

En este contraejemplo en particular, podemos hacer contar ++ atomic utilizando AtomicInteger del paquete «java.util.concurrent.atomic».

import java.util.concurrent.atomic.AtomicInteger;
 
public class MyCounter {
	private static AtomicInteger counter = new AtomicInteger(0);
 
	public static int getCount() {
		return counter.getAndIncrement();
	}
}

Algunos otros datos útiles sobre la seguridad para subprocesos

Las variables locales son seguras para subprocesos en Java.

Cada hilo tiene su propia pila. Dos subprocesos diferentes nunca comparten la misma pila. A todas las variables locales definidas en un método se les asignará memoria en la pila. Tan pronto como el hilo actual complete la ejecución del método, se eliminará el marco de pila.