Le istanze di Java 8 Stream devono sempre essere chiuse () 'd?

Naviga le tue risposte
10

Quella Javadoc :

Streams have a BaseStream.close() method and implement AutoCloseable, but nearly all stream instances do not actually need to be closed after use. Generally, only streams whose source is an IO channel (such as those returned by Files.lines(Path, Charset)) will require closing. Most streams are backed by collections, arrays, or generating functions, which require no special resource management. (If a stream does require closing, it can be declared as a resource in a try-with-resources statement.)

"Quasi tutti" e "generalmente" sono vaghi - se stai scrivendo una libreria e stai astrarre la fonte del tuo stream dagli utenti di quel flusso, allora devi comunque sempre porsi la domanda - " dovrei chiudere questo? " Gli stream con IO-backed devono essere chiusi perché le operazioni del terminale non chiamano close , quindi devo sempre ricordare / documentare da dove proviene il mio stream, o devo sempre close it.

L'opzione nucleare credo sia quella di non restituire gli Stream dai metodi o di accettare i parametri di Stream, che è un sentimento che è stato fatto eco da alcune persone del team JDK. Trovo che sia eccessivamente limitante considerando l'utilità pratica degli Stream.

Quali sono le tue migliori pratiche in merito alla chiusura degli stream? Ho cercato online una risposta a questa domanda da parte di alcuni membri del JDK che di solito sono attivi su domande della community simili, ma non hanno trovato nulla di rilevante.

    
posta RuslanD 18.11.2015 - 21:46
fonte

2 risposte

5

Come hai detto, in Java devi sapere esattamente chi è responsabile della liberazione della risorsa, in modo da poter inserire i costrutti try-catch appropriati, provare con risorse o in qualche modo delegare tale attività.

L'unica cosa che puoi dipendere dal GC per ripulirti è pura memoria al 100%.
Se potrebbe essere inserito in altre risorse, l'unica cosa che puoi ragionevolmente fare è semplicemente quella di andare sul sicuro.

    
risposta data 18.11.2015 - 22:20
fonte
4

Per quanto riguarda le "migliori pratiche", penso che sia una buona idea utilizzare una convenzione di denominazione per i metodi che restituiscono "flussi di risorse".

Se uno stream deve essere close() ed, chiama il metodo factory open() o openStream() . Chiama metodi che costruiscono flussi effimeri stream() , seguendo la convenzione stabilita dall'SDK. Inserisci sempre javadoc sul metodo per avvisare il cliente che deve close() it. 

public interface StreamingServer<RECORD> {
    /** 
     * Return a memory-efficient record stream from {@code source}.
     * Clients <em>must</em> call {@link Stream#close} to dispose the
     * stream.
     */
    Stream<RECORD> openStream(URI source) throws IOException;
}

Vorrei che gli autori dell'SDK non avessero scelto di mettere AutoCloseable sulla classe del flusso di base. Un sottotipo ResourceStream distinto, che implementa banalmente AutoCloseable , avrebbe reso evidenti i diversi contratti. Quindi non puoi chiudere un Stream che non ne ha bisogno e potresti rilevare ResourceStream potenzialmente gestito male negli strumenti di analisi statici.

A seconda delle esigenze del tuo codice base (e della tua capacità di applicare le convenzioni nella revisione del codice), potresti creare tu stesso una sottoclasse di flusso richiesta. O se vuoi creare i tuoi strumenti di analisi statici, un'annotazione di metodo che contrassegna direttamente le risorse gestite. 

@RequiresClose
Stream<RECORD> openStream(URI source) throws IOException { ... }
    
risposta data 11.05.2016 - 19:26
fonte

Leggi altre domande sui tag

modello di progettazione per il test unitario? [duplicare] Uso delle interfacce per codice liberamente accoppiato