Pourquoi BufferedInputStream copie-t-il un champ dans une variable locale plutôt que d'utiliser le champ directement

Quand je lis le code source à partir de java.io.BufferedInputStream.getInIfOpen(), je ne comprends pas pourquoi il a écrit un code comme celui-ci:

/**
 * 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;
}

Pourquoi utilise-t-il l'alias au lieu d'utiliser la variable de champ indirectement comme ci-dessous:

/**
 * 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;
}

Quelqu'un peut-il donner une explication raisonnable?

Si vous regardez ce code hors de son contexte, il n'y a pas de bonne explication pour cet "alias". Il s'agit simplement d'un code redondant ou d'un style de code médiocre.

Mais le contexte est qu'il BufferedInputStreams'agit d'une classe qui peut être sous-classée et qu'elle doit fonctionner dans un contexte multi-thread.

L'indice est qu'il inest déclaré dans FilterInputStreamis protected volatile. Cela signifie qu'il ya une chance qu'une sous - classe pourrait atteindre et assign nullà in. Compte tenu de cette possibilité, «l'alias» est en fait là pour empêcher une condition de concurrence.

Considérez le code sans "alias"

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

1. Thread A appelle getInIfOpen()
2. Le thread A évalue in == nullet voit que ce inn'est pas le cas null.
3. Le thread B est affecté nullà in.
4. Le fil A s'exécute return in. Ce qui revient nullcar ac'est un volatile.

L '"alias" empêche cela. Maintenant, il inest lu une seule fois par le thread A. Si le thread B est affecté nullaprès le thread A, incela n'a pas d'importance. Le thread A lèvera une exception ou renverra une valeur non nulle (garantie).

Cela est dû au fait que la classe BufferedInputStreamest conçue pour une utilisation multi-thread.

Ici, vous voyez la déclaration de in, qui est placée dans la classe parent FilterInputStream:

protected volatile InputStream in;

Comme c'est le cas protected, sa valeur peut être modifiée par n'importe quelle sous-classe de FilterInputStream, y compris BufferedInputStreamet ses sous-classes. En outre, il est déclaré volatile, ce qui signifie que si un thread change la valeur de la variable, ce changement sera immédiatement reflété dans tous les autres threads. Cette combinaison est mauvaise, car cela signifie que la classe BufferedInputStreamn'a aucun moyen de contrôler ou de savoir quand inest modifiée. Ainsi, la valeur peut même être modifiée entre la vérification de null et l'instruction return in BufferedInputStream::getInIfOpen, ce qui rend effectivement la vérification de null inutile. En lisant la valeur de inune seule fois pour la mettre en cache dans la variable locale input, la méthode BufferedInputStream::getInIfOpenest sûre contre les modifications d'autres threads, car les variables locales sont toujours détenues par un seul thread.

Il existe un exemple dans BufferedInputStream::close, qui est défini insur null:

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::closeest appelé par un autre thread pendant l' BufferedInputStream::getInIfOpenexécution, cela entraînerait la condition de concurrence décrite ci-dessus.

C'est un tel code court, mais, théoriquement, dans un environnement multi-thread, inpeut changer juste après la comparaison, de sorte que la méthode pourrait renvoyer quelque chose qu'elle n'a pas vérifié (elle pourrait renvoyer null, faisant ainsi exactement la chose à laquelle elle était censée prévenir).

Je pense que la capture de la variable de classe indans la variable locale permet inputd'éviter un comportement incohérent en cas de inmodification par un autre thread pendant l' getInIfOpen()exécution.

Notez que le propriétaire de inest la classe parente et ne la marque pas comme final.

Ce modèle est reproduit dans d'autres parties de la classe et semble être un codage défensif raisonnable.