¿Por qué BufferedInputStream copia un campo en una variable local en lugar de usar el campo directamente?

Cuando leo el código fuente de java.io.BufferedInputStream.getInIfOpen(), estoy confundido acerca de por qué escribió un código como este:

/**
 * Check to make sure that underlying input stream has not been
 * nulled out due to close; if not return it;
 */
private InputStream getInIfOpen() throws IOException {
    InputStream input = in;
    if (input == null)
        throw new IOException("Stream closed");
    return input;
}

¿Por qué usa el alias en lugar de usar la variable de campo indirectamente como se muestra a continuación?

/**
 * Check to make sure that underlying input stream has not been
 * nulled out due to close; if not return it;
 */
private InputStream getInIfOpen() throws IOException {
    if (in == null)
        throw new IOException("Stream closed");
    return in;
}

¿Alguien puede dar una explicación razonable?

Si observa este código fuera de contexto, no hay una buena explicación para ese "alias". Es simplemente código redundante o estilo de código deficiente.

Pero el contexto es que BufferedInputStreames una clase que puede subclasificarse y que necesita funcionar en un contexto de subprocesos múltiples.

La pista es que inse declara en FilterInputStreamis protected volatile. Eso significa que hay una posibilidad de que una subclase puede meter la mano y asignar nulla in. Dada esa posibilidad, el "alias" está realmente ahí para evitar una condición de carrera.

Considere el código sin el "alias"

private InputStream getInIfOpen() throws IOException {
    if (in == null)
        throw new IOException("Stream closed");
    return in;
}

1. Llamadas del hilo A getInIfOpen()
2. El hilo A evalúa in == nully ve que inno lo es null.
3. El hilo B se asigna nulla in.
4. Enhebrar realiza un return in. Que devuelve nullporque aes un volatile.

El "alias" evita esto. Ahora inse lee solo una vez por el hilo A. Si el hilo B se asigna nulldespués del hilo A in, no importa. El hilo A lanzará una excepción o devolverá un valor no nulo (garantizado).

Esto se debe a que la clase BufferedInputStreamestá diseñada para uso de subprocesos múltiples.

Aquí, ve la declaración de in, que se coloca en la clase principal FilterInputStream:

protected volatile InputStream in;

Dado que lo es protected, su valor puede ser cambiado por cualquier subclase de FilterInputStream, incluyendo BufferedInputStreamy sus subclases. Además, se declara volatile, lo que significa que si algún hilo cambia el valor de la variable, este cambio se reflejará inmediatamente en todos los demás hilos. Esta combinación es mala, ya que significa que la clase BufferedInputStreamno tiene forma de controlar o saber cuándo inse cambia. Por lo tanto, el valor incluso se puede cambiar entre la verificación de nulo y la declaración de retorno en BufferedInputStream::getInIfOpen, lo que efectivamente hace que la verificación de nulo sea inútil. Al leer el valor de insolo una vez para almacenarlo en caché en la variable local input, el método BufferedInputStream::getInIfOpenes seguro contra cambios de otros subprocesos, ya que las variables locales siempre son propiedad de un solo subproceso.

Hay un ejemplo en BufferedInputStream::close, que se establece inen nulo:

public void close() throws IOException {
    byte[] buffer;
    while ( (buffer = buf) != null) {
        if (bufUpdater.compareAndSet(this, buffer, null)) {
            InputStream input = in;
            in = null;
            if (input != null)
                input.close();
            return;
        }
        // Else retry in case a new buf was CASed in fill()
    }
}

Si BufferedInputStream::closees llamado por otro hilo mientras BufferedInputStream::getInIfOpense ejecuta, esto daría como resultado la condición de carrera descrita anteriormente.

Este es un código tan corto, pero, teóricamente, en un entorno de subprocesos múltiples, inpuede cambiar justo después de la comparación, por lo que el método podría devolver algo que no verificó (podría regresar null, haciendo así exactamente lo que estaba destinado a hacer evitar).

Creo que capturar la variable de clase inen la variable local inputes para evitar un comportamiento inconsistente si inotro subproceso lo cambia mientras se getInIfOpen()está ejecutando.

Tenga en cuenta que el propietario de ines la clase principal y no la marca como final.

Este patrón se replica en otras partes de la clase y parece ser una codificación defensiva razonable.