Чому 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. Нитка дзвінків getInIfOpen()
2. Нитка А оцінює in == nullі бачить, що inце не так null.
3. Тема B правонаступників nullдо in.
4. Нитка А виконується return in. Який повертається, nullтому що aє volatile.

"Псевдонім" цьому заважає. Тепер inчитається лише один раз за темою A. Якщо нитка B призначається nullпісля потоку A, inце не має значення. Нитка A або кине виняток, або поверне (гарантоване) ненулеве значення.

Це тому, що клас BufferedInputStreamпризначений для багатопотокового використання.

Тут ви бачите декларацію in, яка розміщується в батьківському класі FilterInputStream:

protected volatile InputStream in;

Оскільки воно є protected, його значення може бути змінено будь-яким підкласом FilterInputStream, включаючи BufferedInputStreamі його підкласи. Крім того, це оголошено volatile, що означає, що якщо будь-який потік змінює значення змінної, ця зміна буде негайно відображена у всіх інших потоках. Ця комбінація погана, оскільки означає, що у класу BufferedInputStreamнемає способу контролювати чи знати, коли inвін змінюється. Таким чином, значення навіть може бути змінено між чеком на null та оператором return у BufferedInputStream::getInIfOpen, що фактично робить перевірку на null марною. Прочитавши значення inлише одного разу для кешування його в локальній змінній input, метод BufferedInputStream::getInIfOpenзахищений від змін з інших потоків, оскільки локальні змінні завжди належать одному потоку.

Є приклад в BufferedInputStream::close, який встановлює inнульове значення:

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.

Ця модель повторюється в інших частинах класу і, здається, є розумним оборонним кодуванням.