Czy muszę zamykać () zarówno FileReader, jak i BufferedReader?

Czytam plik lokalny za pomocą BufferedReader owiniętego wokół FileReader:

BufferedReader reader = new BufferedReader(new FileReader(fileName));
// read the file
// (error handling snipped)
reader.close();

Czy muszę , jak również, czy będzie uchwyt wrapper że? Widziałem kod, w którym ludzie robią coś takiego:close()FileReader

FileReader fReader = new FileReader(fileName);
BufferedReader bReader = new BufferedReader(fReader);
// read the file
// (error handling snipped)
bReader.close();
fReader.close();

Ta metoda jest wywoływana z serwletu i chciałbym się upewnić, że nie zostawię otwartych uchwytów.

Nie.

BufferedReader.close()

zamyka strumień zgodnie z javadoc dla BufferedReader i InputStreamReader

jak również

FileReader.close()

robi.

Jak zauważyli inni, wystarczy zamknąć zewnętrzne opakowanie.

BufferedReader reader = new BufferedReader(new FileReader(fileName));

Istnieje bardzo niewielka szansa, że ​​może to spowodować wyciek uchwytu pliku, jeśli BufferedReaderkonstruktor zgłosi wyjątek (npOutOfMemoryError .). Jeśli aplikacja jest w tym stanie, to, jak ostrożne musi być czyszczenie, może zależeć od tego, jak ważne jest, aby nie pozbawiać systemu operacyjnego zasobów, które może chcieć przydzielić innym programom.

Zamykane interfejs może być stosowane, jeżeli konstruktor wrapper może zawieść w Java 5 lub 6:

Reader reader = new FileReader(fileName);
Closeable resource = reader;
try {
  BufferedReader buffered = new BufferedReader(reader);
  resource = buffered;
  // TODO: input
} finally {
  resource.close();
}

Kod Java 7 powinien używać wzorca try-with-resources :

try (Reader reader = new FileReader(fileName);
    BufferedReader buffered = new BufferedReader(reader)) {
  // TODO: input
}

Według źródła BufferedReader, w tym przypadku bReader.close wywołuje fReader.close, więc technicznie nie trzeba wywoływać tego ostatniego.

Kod źródłowy dla BufferedReader pokazuje, że instrument bazowy jest zamknięty po zamknięciu BufferedReader.

Po sprawdzeniu kodu źródłowego znalazłem to na przykład:

FileReader fReader = new FileReader(fileName);
BufferedReader bReader = new BufferedReader(fReader);

metoda close () na obiekcie BufferedReader wywołałaby abstrakcyjną metodę close () klasy Reader, która ostatecznie wywołałaby zaimplementowaną metodę w klasie InputStreamReader , która następnie zamyka obiekt InputStream .

Tak więc wystarczy tylko bReader.close ().

Począwszy od wersji Java 7 można użyć instrukcji try-with-resources

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
}

Ponieważ BufferedReaderinstancja jest zadeklarowana w instrukcji try-with-resource, zostanie zamknięta niezależnie od tego, czy instrukcja try zakończy się normalnie czy nagle. Więc nie musisz go sam zamykać w finallywyciągu. (Dotyczy to również zagnieżdżonych instrukcji zasobów)

Jest to zalecany sposób pracy z zasobami, więcej informacji można znaleźć w dokumentacji

Musisz tylko zamknąć bufferedReader tj. Reader.close () i będzie działał dobrze.

Jestem spóźniony, ale:

BufferReader.java:

public BufferedReader(Reader in) {
  this(in, defaultCharBufferSize);
}

(...)

public void close() throws IOException {
    synchronized (lock) {
        if (in == null)
            return;
        try {
            in.close();
        } finally {
            in = null;
            cb = null;
        }
    }
}

Ty Nie trzeba zamknąć owinięte odczytującego / zapisującego.

Jeśli spojrzałeś na dokumenty ( Reader.close(), Writer.close()), zobaczysz, że w Reader.close()nim jest napisane:

Zamyka strumień i uwalnia wszelkie związane z nim zasoby systemowe.

Co tylko mówi, że „uwalnia wszelkie związane z tym zasoby systemowe ”. Mimo że nie potwierdza ... daje ci ochotę zacząć szukać głębiej. a jeśli pójdziesz doWriter.close() niego to tylko stwierdza, że ​​się zamyka.

W takich przypadkach odsyłamy do OpenJDK, aby spojrzeć na kod źródłowy.

W BufferedWriter Line 265 zobaczysz out.close(). Więc to się nie zamyka ... To coś innego. Jeśli przeszukasz klasę pod kątem występowania „ out”, zauważysz, że w konstruktorze w linii 87, która outjest pisarzem, klasa zawija się tam, gdzie wywołuje innego konstruktora, a następnie przypisuje outparametr do własnej outzmiennej.

Więc .. Co z innymi? Podobny kod można zobaczyć w BufferedReader Line 514 , BufferedInputStream Line 468 i InputStreamReader Line 199 . Inni nie znam, ale to powinno wystarczyć, by założyć, że tak.