Warum kopiert BufferedInputStream ein Feld in eine lokale Variable, anstatt das Feld direkt zu verwenden?

Wenn ich den Quellcode auslese java.io.BufferedInputStream.getInIfOpen()ich bin verwirrt darüber, warum es Code wie diesen geschrieben hat:

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

Warum wird der Alias ​​verwendet, anstatt die Feldvariable zu verwenden in direkt wie unten:

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

Kann jemand eine vernünftige Erklärung geben?

Wenn Sie sich diesen Code aus dem Kontext reißen, gibt es keine gute Erklärung für diesen “Alias”. Es ist einfach redundanter Code oder schlechter Codestil.

Aber der Kontext ist das BufferedInputStream ist eine Klasse, die in Unterklassen unterteilt werden kann und die in einem Kontext mit mehreren Threads funktionieren muss.

Der Hinweis ist das in deklariert ist FilterInputStream ist protected volatile. Das bedeutet, dass die Möglichkeit besteht, dass eine Unterklasse eingreifen und zuweisen kann null zu in. Angesichts dieser Möglichkeit ist der “Alias” eigentlich dazu da, eine Racebedingung zu verhindern.

Betrachten Sie den Code ohne den “Alias”

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

1. Thread A ruft auf getInIfOpen()
2. Thread A wertet aus in == null und sieht das in ist nicht null.
3. Thread B weist zu null zu in.
4. Thread A wird ausgeführt return in. Was zurückkehrt null Weil a ist ein volatile.

Der “Alias” verhindert dies. Jetzt in wird nur einmal von Thread A gelesen. Wenn Thread B zuweist null nachdem Thread A hat in es spielt keine Rolle. Thread A löst entweder eine Ausnahme aus oder gibt einen (garantierten) Nicht-Null-Wert zurück.

Das liegt an der Klasse BufferedInputStream ist für die Multithread-Nutzung ausgelegt.

Hier sehen Sie die Deklaration von indie in der übergeordneten Klasse platziert wird FilterInputStream:

protected volatile InputStream in;

Seit es ist protectedsein Wert kann von jeder Unterklasse von geändert werden FilterInputStreameinschließlich BufferedInputStream und seine Unterklassen. Außerdem ist es deklariert volatile, was bedeutet, dass wenn ein Thread den Wert der Variablen ändert, diese Änderung sofort in allen anderen Threads widergespiegelt wird. Diese Kombination ist schlecht, da sie die Klasse bedeutet BufferedInputStream hat keine Möglichkeit zu kontrollieren oder zu wissen, wann in ist geändert. Somit kann der Wert sogar zwischen der Prüfung auf null und der return-Anweisung in geändert werden BufferedInputStream::getInIfOpen, was die Überprüfung auf null effektiv nutzlos macht. Durch Lesen des Wertes von in nur einmal, um es in der lokalen Variablen zwischenzuspeichern inputdie Methode BufferedInputStream::getInIfOpen ist sicher gegen Änderungen von anderen Threads, da lokale Variablen immer einem einzelnen Thread gehören.

Ein Beispiel ist drin BufferedInputStream::closedie setzt in zu 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()
    }
}

Wenn BufferedInputStream::close wird dabei von einem anderen Thread aufgerufen BufferedInputStream::getInIfOpen ausgeführt wird, würde dies zu der oben beschriebenen Wettlaufbedingung führen.

Dies ist ein so kurzer Code, aber theoretisch in einer Multithread-Umgebung in kann sich direkt nach dem Vergleich ändern, sodass die Methode etwas zurückgeben könnte, das sie nicht überprüft hat (sie könnte zurückgeben nullund tat damit genau das, was es verhindern sollte).

Ich glaube, die Klassenvariable zu erfassen in auf die lokale Variable input ist es, inkonsequentes Verhalten zu verhindern, wenn in wird zwar durch einen anderen Thread geändert getInIfOpen() läuft.

Beachten Sie, dass der Besitzer von in ist die übergeordnete Klasse und wird nicht als markiert final.

Dieses Muster wird in anderen Teilen der Klasse repliziert und scheint eine vernünftige defensive Codierung zu sein.