zamykające inputstreams w Javie

Question

Mam następujący fragment kodu w bloku try/catch

InputStream inputstream = conn.getInputStream(); 
InputStreamReader inputstreamreader = new InputStreamReader(inputstream); 
BufferedReader bufferedreader = new BufferedReader(inputstreamreader); 

moje pytanie jest, że kiedy mam do zamknięcia tych strumieni w bloku finally, muszę zamknąć wszystkie 3 strumienie lub po prostu zamknięcie czytnikazamkną wszystkie inne strumienie?

Answer 1

Zgodnie z konwencją, strumienie owijki (które zawijają istniejące strumienie) zamykają zamknięty strumień, gdy są zamknięte, tak więc należy tylko zamykać bufferedreader w twoim przykładzie. Poza tym zamknięcie już zamkniętego strumienia jest zwykle nieszkodliwe, więc zamknięcie wszystkich 3 strumieni nie zaszkodzi.

Answer 2

Zgodnie z ogólną zasadą zamknij wszystko w odwrotnej kolejności, w jakiej je otworzyłeś.

Answer 3

chciałbym zamknąć wszystkie z nich w odwrotnej kolejności, od których je otworzył, jakby podczas otwierania ich doprowadziłaby czytelnika do stosu i zamykanie będzie pop czytelnika ze stosu.

W końcu, po zamknięciu wszystkich, „stos czytelnik” musi być pusta.

Answer 4

Zamknięcie jedną zewnętrzną jest wystarczająca (tj BufferedReader). Czytając source code of BufferedReader widzimy, że to zamyka wewnętrzny Reader gdy jego własna blisko metoda nazywa się:

513  public void close() throws IOException { 
514   synchronized (lock) { 
515    if (in == null) 
516     return; 
517    in.close(); 
518    in = null; 
519    cb = null; 
520   } 
521  } 
522 } 

Answer 5

Wystarczy tylko zamknąć rzeczywistego zasobu. Należy zamknąć zasób, nawet jeśli nie uda się zbudować dekoratorów. Aby uzyskać wynik, należy opróżnić obiekt najbardziej dekorator w szczęśliwym przypadku.

Niektóre powikłania:

• Czasami dekoratorzy są różne zasoby (niektóre implementacje kompresji użyć C sterty).
• Zamknięcie dekoratorów w smutnych przypadkach faktycznie powoduje opróżnienia, co powoduje zamieszanie, które nie powoduje zamknięcia zasób.
• Wygląda na to, że zasób będący podstawą to URLConnection, który nie ma metody jako takiej.

Możesz rozważyć użycie polecenia Wykonaj dookoła, aby nie musieć duplikować tego typu rzeczy.

Answer 6

Normalnie jest ok po prostu zamknąć najbardziej zewnętrzną strumienia, ponieważ zgodnie z przyjętą konwencją musi wyzwalać blisko na strumieniach bazowych.

Więc normalnie kod wygląda następująco:

BufferedReader in = null; 

try { 
    in = new BufferedReader(new InputStreamReader(conn.getInputStream())); 
    ... 
    in.close(); // when you care about Exception-Handling in case when closing fails 
} 
finally { 
    IOUtils.closeQuietly(in); // ensure closing; Apache Commons IO 
} 

jednak nie mogą być rzadkie przypadki, w których strumień bazowy konstruktor zgłasza wyjątek, jeśli strumień jest już otwarty. W takim przypadku powyższy kod nie zamknie strumienia bazowego, ponieważ zewnętrzny konstruktor nigdy nie został wywołany, a in ma wartość null. Tak więc blok finally nie zamyka niczego pozostawiając otwarty strumień bazowy.

Ponieważ Java 7 można to zrobić:

try (OutputStream out1 = new ...; OutputStream out2 = new ...) { 
     ... 
     out1.close(); //if you want Exceptions-Handling; otherwise skip this 
     out2.close(); //if you want Exceptions-Handling; otherwise skip this    
    } // out1 and out2 are auto-closed when leaving this block 

W większości przypadków nie chcesz obsługi wyjątków, gdy podniesiona podczas zamykania więc pominąć te wyraźny Close() zwraca.

Edytuj Oto kod dla niewierzących, w przypadku gdy użycie tego wzoru jest zasadne. Możesz także przeczytać Apache Commons IOUtils javadoc o metodzie closeQuietly().

OutputStream out1 = null; 
    OutputStream out2 = null; 

    try { 
     out1 = new ...; 
     out2 = new ...; 

     ... 

     out1.close(); // can be skipped if we do not care about exception-handling while closing 
     out2.close(); // can be skipped if we ... 
    } 
    finally { 
     /* 
     * I've some custom methods in my projects overloading these 
     * closeQuietly() methods with a 2nd param taking a logger instance, 
     * because usually I do not want to react on Exceptions during close 
     * but want to see it in the logs when it happened. 
     */ 
     IOUtils.closeQuietly(out1); 
     IOUtils.closeQuietly(out2); 
    } 

Korzystanie @ Toma „porady” pozostawi out1 otwarty, gdy stworzenie out2 podnosi wyjątek. Ta rada pochodzi od kogoś, kto mówi o It's a continual source of errors for obvious reasons. Cóż, mogę być ślepy, ale nie jest to dla mnie oczywiste. Mój wzorzec jest bezpieczny dla idioty w każdym przypadku użycia, jaki mogę sobie wyobrazić, podczas gdy wzorzec Toma jest podatny na błędy.