Dlaczego BufferedInputStream kopiuje pole do zmiennej lokalnej, zamiast używać pola bezpośrednio

Kiedy czytam kod źródłowy java.io.BufferedInputStream.getInIfOpen(), nie rozumiem, dlaczego napisał on taki kod:

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

Dlaczego używa aliasu zamiast używać zmiennej pola inbezpośrednio, jak poniżej:

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

Czy ktoś może podać rozsądne wyjaśnienie?

Jeśli spojrzysz na ten kod z kontekstu, nie ma dobrego wyjaśnienia tego „aliasu”. Jest to po prostu nadmiarowy kod lub słaby styl kodu.

Ale kontekst jest taki, że BufferedInputStreamjest to klasa, która może być podklasą i że musi działać w kontekście wielowątkowym.

Wskazówka jest taka, że inzadeklarowano w FilterInputStreamis protected volatile. Oznacza to, że istnieje szansa, że ​​podklasa może dotrzeć do i przypisać nulldo in. Biorąc pod uwagę taką możliwość, „alias” faktycznie istnieje, aby zapobiec sytuacji wyścigu.

Rozważ kod bez „aliasu”

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

1. Wątek wywołuje getInIfOpen()
2. Wątek A ocenia in == nulli widzi, że intak nie jest null.
3. Wątek B przypisuje nulldo in.
4. Wątek wykonuje return in. Który powraca, nullponieważ ajest volatile.

„Alias” zapobiega temu. Teraz injest czytany tylko raz przez wątek A. Jeśli wątek B przypisuje się nullpo wątku A in, nie ma to znaczenia. Wątek A zgłosi wyjątek lub zwróci (gwarantowaną) wartość różną od null.

Dzieje się tak, ponieważ klasa BufferedInputStreamjest przeznaczona do użytku wielowątkowego.

Tutaj widzisz deklarację in, która jest umieszczona w klasie nadrzędnej FilterInputStream:

protected volatile InputStream in;

Ponieważ tak jest protected, jego wartość może zostać zmieniona przez dowolną podklasę FilterInputStream, w tym BufferedInputStreami jej podklasy. Ponadto jest zadeklarowana volatile, co oznacza, że ​​jeśli którykolwiek wątek zmieni wartość zmiennej, ta zmiana zostanie natychmiast odzwierciedlona we wszystkich innych wątkach. Ta kombinacja jest zła, ponieważ oznacza, że ​​klasa BufferedInputStreamnie może kontrolować ani wiedzieć, kiedy inzostanie zmieniona. W związku z tym wartość można nawet zmienić między sprawdzeniem wartości null a instrukcją return in BufferedInputStream::getInIfOpen, co skutecznie sprawia, że ​​sprawdzanie wartości null jest bezużyteczne. Odczytując wartość intylko raz w celu buforowania jej w zmiennej lokalnej input, metoda BufferedInputStream::getInIfOpenjest zabezpieczona przed zmianami z innych wątków, ponieważ zmienne lokalne są zawsze własnością jednego wątku.

Oto przykład w programie BufferedInputStream::close, który ustawia inwartość 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()
    }
}

Jeśli BufferedInputStream::closejest wywoływana przez inny wątek podczas BufferedInputStream::getInIfOpenwykonywania, spowodowałoby to sytuację wyścigu opisaną powyżej.

To jest taki krótki kod, ale teoretycznie w środowisku wielowątkowym inmoże się zmienić zaraz po porównaniu, więc metoda może zwrócić coś, czego nie sprawdzała (mogła zwrócić null, robiąc dokładnie to, do czego była przeznaczona zapobiec).

Uważam, że przechwycenie zmiennej klasy indo zmiennej lokalnej inputma zapobiec niespójnemu zachowaniu, jeśli inzostanie zmieniony przez inny wątek podczas getInIfOpen()działania.

Zwróć uwagę, że właścicielem injest klasa nadrzędna i nie oznacza jej jako final.

Ten wzorzec jest powielany w innych częściach klasy i wydaje się być rozsądnym kodowaniem obronnym.