"Java concurrencia en combate", señala el estudio (1)

Capítulo Uno: Introducción

puntos de conocimiento :

• Proceso es de recursos (CPU, memoria, etc.) asignados a la unidad básica
• Un hilo es la unidad básica de planificación de la CPU y despacho
• Un proceso que incluye uno o más hilos

1, ¿por qué la aplicación tiene que desarrollarse a partir de un único subproceso de multi-hilo (de sincrónica a asíncrona)?

• la utilización de recursos . A veces es necesario esperar a que las operaciones externas, tales como la entrada y salida, y no puede realizar un trabajo valioso a la espera. Mientras espera, de manera que otros programas mejorarán la eficiencia operativa.
• Feria . Varios usuarios o programas pueden tener la misma prioridad de recursos del sistema. Les permiten compartir porción de tiempo del ordenador a través de mejores caminos, más deseable que los siguientes extremos programa después del inicio de un programa.
• Conveniente . Escribir algunos procedimientos, de manera que cada uno realiza una tarea única y facilitará la coordinación necesaria, que es mejor que escribir un programa para realizar todas las tareas más fácil y más satisfactorio.

Capítulo II: flujos seguros

de un objeto estado es sus datos . Escribir código seguro para subprocesos, en esencia, es la gestión del estado de visita (estado), y son a menudo compartida , la variable de estado.

El llamado intercambio , se refiere a una variable se puede acceder por múltiples hilos; la llamada variable de se refiere al valor de la variable puede cambiar durante su ciclo de vida. Seguridad de los hilos de nuestra discusión parece estar a punto el código, pero que realmente necesita hacer, es para proteger los datos en el acceso concurrente no se controla.

En ausencia de una adecuada sincronización, si varios subprocesos tienen acceso a la misma variable, su programa no hay riesgo. Hay tres maneras de solucionarlo:

• Hacer las variables no se comparte a través del hilo;
• Una variable de estado es inmutable; o
• el acceso síncrono a cualquier variable de estado de tiempo.

Hilo de seguridad definición:

Cuando varios subprocesos tienen acceso a una clase, si no se consideran programación alternativa y ejecución de estos hilos en el entorno de ejecución, y no requiere una sincronización adicional y el código de la persona que llama no tiene otro comportamiento coordinación de esta clase sigue siendo correcta a continuación, llamar a esta clase es seguro para subprocesos de.

objetos sin estado son siempre seguro para subprocesos.

Hilo de la inseguridad operación compleja

Leer - cambio - escritura (lectura-modificación-escritura)

@NotThreadSafe
public class UnsafeCountingFactorizer implements Servlet {
    private long count = 0;
    public long getCount() { return count; }
    public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = factor(i);
        ++count;
        encodeIntoResponse(resp, factors);
    }
}

Controle el curso (Check-Act)

@NotThreadsafe
public class LazyInitRace {
    private Expensive0bject instance = null;
    public ExpensiveObject getInstance() {
        if ( instance == null ) {
            instance = new Expensive0bject();
        }
        return instance;
    }
}

Con el fin de garantizar, operaciones compatibles con el proceso de verificación "run" (tales como la inicialización perezosa) y leen - Modificar - operaciones de escritura (como mínimo de la subasta) deben ser atómicas. Vamos a "control de funcionamiento" y "Read - cambio - escribir" todo el proceso de ejecución como una operación compleja: Con el fin de garantizar un funcionamiento seguro para subprocesos DEBE ser realizado de forma atómica.

En la siguiente sección vamos a considerar el uso de Java incorporado mecanismos atómicos - cerraduras. Ahora, vamos a solucionar este problema en otras formas - con ayuda de las clases seguras para subprocesos existentes.

@ThreadSafe
public class CountingFactorizer implements Servlet {
    private final AtomicLong count = new AtomicLong(0);
    public long getCount() { return count.get(); }
    public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = factor(i);
        count.incrementAndGet();
        encodeIntoResponse(resp, factors);
    }
}

java.util.concurrent.atomicEl paquete incluye átomos de variables (variables atómica) para implementar clases estados atómicos de las referencias de conversión y de objetos digitales. Los longtipos alternativos de venta libre AtomicLongtipos, podemos asegurar que todos los accesos a estado del contador son atómicos. Los contadores son thread-safe.

bloqueo interno

Java proporciona un mecanismo atómicas el bloqueo incorporado forzados: synchronized. Un synchronizedbloque que tiene dos partes: el objeto de bloqueo se hace referencia, y el bloque de código de protección de bloqueo.

Cada objeto Java puede jugar un papel bloquear implícitamente para la sincronización; incorporados en estas cerraduras se llama bloqueo interior (cerraduras intrínsecas) o un bloqueo del monitor (monitor cerraduras).

hilo de ejecución para entrar synchronizedy salir a través de la normal, independientemente de la vía de control, o lanzado desde el bloque, los hilos son a renunciar; bloqueará automáticamente hasta que el bloqueo synchronizedse libera automáticamente cuando el bloque de control de bloqueo.

La única manera de conseguir dentro de la cerradura es: El método para introducir el bloque de sincronización o proteger el bloqueo interno.

bloqueo interno jugado en Java mutex (exclusión mutua de bloqueo, también llamado un mutex) papel, lo que significa que a lo sumo sólo un hilo puede ser dueño de la cerradura, cuando el hilo Un hilo está tratando de solicitar un bloqueo B ocupado, hilo Una visita obligada espere hasta que el bloque B o lo suelte. Si B no libera el bloqueo, un esperará para siempre.

Re-entrada (reentrancia)

Cuando un hilo pide otro hilo ya tiene un bloqueo, se bloquea el hilo solicitante. Sin embargo, se volvió a entrar en bloqueo interno, de manera que el hilo en su propio tiempo tratando de conseguir la posesión de la cerradura, la solicitud será exitosa.

medios de reentrada que la solicitud se basa en " per-hilo (por subproceso)", en lugar de en " por llamada (per-invocación)" es.

Esto se logra mediante el reingreso a un recuento petición asociada a cada cerradura (recuento de adquisición) y un hilo es el dueño. Cuando el recuento es 0, que el bloqueo está desocupada.

Cuando un hilo pide al bloqueo desocupada, la JVM grabación de bloqueo de los ocupantes, y el recuento solicitud se establece en 1. Si el mismo hilo de nuevo pide al bloqueo de recuento se incrementa; bloques de sincronización cada uno con salidas de rosca, se decrementa el valor del contador. Hasta los alcances cero del contador, el bloqueo se libera.

/**
*	如果该锁不是可重入的，代码将死锁
*/
public class Widget {
	public synchronized void doSomething() {
		...
	}
}
public class LoggingWidget extends Widget {
	@Override
	public synchronized void doSomething() {
		super.doSomething();
	}
}

Para cada variable de estado variable se puede acceder por múltiples hilos, si todo el acceso que ha jugado en la implementación de la rosca con una cerradura, en cuyo caso, llamamos a esta variable es la protección de bloqueo.

Cada variable variables compartidas necesidad de bloquear protegida por una sola determinado.

Ajustar synchronizedel tamaño del bloque, a fin de lograr un equilibrio entre la seguridad y el rendimiento.

Cálculo o algunas operaciones que requieren mucho tiempo, como la consola o una red de E / S, es difícil rápidamente. No bloquear la posesión durante la ejecución de estas operaciones.