BufferedInputStreamがフィールドを直接使用するのではなく、フィールドをローカル変数にコピーする理由

からソースコードを読んだときjava.io.BufferedInputStream.getInIfOpen()、なぜ次のようにコードを書いたのか混乱します。

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

in以下のようにフィールド変数を直接使用するのではなく、エイリアスを使用するのはなぜですか？

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

誰かが合理的な説明をすることができますか？

このコードをコンテキスト外で見ると、その「エイリアス」についての適切な説明はありません。これは単に冗長なコードまたは貧弱なコードスタイルです。

しかし、コンテキストは、BufferedInputStreamサブクラス化できるクラスであり、マルチスレッドコンテキストで機能する必要があるということです。

手がかりはでin宣言されていることFilterInputStreamですprotected volatile。これは、サブクラスが到達してに割り当てnullられる可能性があることを意味しinます。その可能性を考えると、「エイリアス」は実際には競合状態を防ぐために存在します。

「エイリアス」のないコードを検討してください

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

1. スレッドA呼び出し getInIfOpen()
2. スレッドAは評価しin == null、inそうでないことを確認しnullます。
3. Bが割り当てるスレッドnullにin。
4. スレッドAが実行されreturn inます。どちらを返すnullためaですvolatile。

「エイリアス」はこれを防ぎます。今、inスレッドBが割り当てる場合は、スレッドAによって一度だけ読まれnullたスレッドAが持っていた後、inそれは問題ではありません。スレッドAは、例外をスローするか、（保証された）null以外の値を返します。

これは、クラスBufferedInputStreamがマルチスレッド用に設計されているためです。

ここでinは、親クラスに配置されたの宣言が表示されていFilterInputStreamます。

protected volatile InputStream in;

なのでprotected、その値は、およびそのサブクラスFilterInputStreamを含むBufferedInputStream、の任意のサブクラスによって変更できます。また、宣言されてvolatileいます。つまり、いずれかのスレッドが変数の値を変更した場合、この変更はすぐに他のすべてのスレッドに反映されます。これは、クラスBufferedInputStreamがいつin変更されるかを制御または知る方法がないため、この組み合わせは不適切です。したがって、nullのチェックとのreturnステートメントの間で値を変更することもできBufferedInputStream::getInIfOpenます。これにより、nullのチェックは事実上役に立たなくなります。ローカル変数は常に1つのスレッドによって所有されるため、値をin1回だけ読み取ってローカル変数にキャッシュすることinputにより、メソッドBufferedInputStream::getInIfOpenは他のスレッドからの変更に対して安全です。

に例があります BufferedInputStream::closeinnullに設定にあります。

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()
    }
}

実行BufferedInputStream::close中に別のスレッドから呼び出された場合BufferedInputStream::getInIfOpen、上記の競合状態が発生します。

これは非常に短いコードですが、理論的には、マルチスレッド環境でinは、比較の直後に変更される可能性があるため、メソッドはチェックしていないものを返す可能性があります（nullつまり、防ぐ）。

クラス変数inをローカル変数にキャプチャinputすることは、実行in中に別のスレッドによって変更された場合の一貫性のない動作を防ぐためだと思いますgetInIfOpen()。

の所有者inは親クラスであり、としてマークされていないことに注意してくださいfinal。

このパターンはクラスの他の部分で複製され、合理的な防御コーディングのようです。