Perché lo streaming Java close() dopo l'emissione di un'operazione terminale?

Question

Dopo aver letto https://www.airpair.com/java/posts/spring-streams-memory-efficiency, sono tentato di trasmettere i risultati da un database, ma come ho discusso con un collega (cfr. Commento che ha aggiunto a questo articolo), è necessario ricordare di usare il costrutto try-with-resources per evitare eventuali perdite di memoria.

1. Perché non l'8 libreria Java prendersi cura di chiusura corsi d'acqua per sé dopo ogni terminal operation (senza dover avvolgere l'istanza flusso in una prova-con-risorse)?
2. Se applicabile, ci sono piani per questa funzionalità da aggiungere a Java o avrebbe senso richiederla?

Answer 1

Poiché gli stream che richiedono il rilascio esplicito di risorse sono in realtà un caso piuttosto insolito. Quindi abbiamo scelto di non sovraccaricare l'esecuzione di streaming con qualcosa che è valido solo per lo 0,01% degli usi.

Abbiamo fatto flusso Autocloseable in modo che sia possibile risorse liberazione dalla fonte, se si vuole, ma questo è dove ci siamo fermati, e per una buona ragione.

Non solo farebbe questo automaticamente a carico della maggior parte degli utenti con un lavoro extra di cui non hanno bisogno, ma ciò violerebbe anche un principio generale: colui che assegna la risorsa è responsabile della chiusura della risorsa. Quando si chiama

BufferedReader reader = ... 
reader.lines().op().op()... 

si sta aprendo la risorsa, non la libreria torrente l'uno e si dovrebbe chiuderlo. Infatti, poiché chiudere un flusso risultante dalla chiamata di un metodo di accesso su un oggetto che tiene risorse a volte chiude l'oggetto sottostante, probabilmente non vuoi che lo streaming chiuda il BufferedReader per te - potresti voler che rimanga aperto dopo il chiamata.

Se si desidera chiudere la risorsa, questo è troppo facile:

try (BufferedReader reader = ...) { 
    reader.lines().op()... 
} 

Probabilmente stai utilizzando i flussi in modo particolare, quindi probabilmente sembra "evidente" che cosa flussi dovrebbe fare - ma ci sono più casi d'uso là fuori che i tuoi. Quindi, piuttosto che ricorrere a casi d'uso specifici, ci siamo avvicinati dal principio generale: se hai aperto il flusso e lo vuoi chiuso, chiudilo da solo, ma se non lo hai aperto, non è per te che devi chiudere.

Answer 2

Perché non l'8 libreria Java prendersi cura di se stessa chiusura flussi dopo ogni operazione terminale (senza dover avvolgere l'istanza flusso in una prova-con-risorse)?

Perché si può verificare un'eccezione durante o prima dell'operazione del terminale e perché non si desidera che l'operazione del terminale chiuda il flusso. Puoi usare try-with-resource se vuoi che lo stream si chiuda.

Se applicabile, ci sono piani per questa funzionalità da aggiungere a Java o avrebbe senso richiederlo?

Non avrebbe senso vedere la risposta sopra.

Answer 3

Penso che stai mescolando java.io.InputStream con java.util.stream.Stream, che sono due concetti molto molto diversi.

try-with-resources funziona su oggetti che implementano l'interfaccia Autoclosable, ad esempio InputStream s. InputStream s rappresentano una fonte astratta di dati relativi a IO.

java.util.stream.Stream<T> d'altro canto, implementa un concetto di programmazione funzionale, che rappresenta una sorta di collezione dinamica che non è necessariamente costruita staticamente, ma può piuttosto essere generata, e potenzialmente potenzialmente infinita.

Ciò che Marko Topolnik (l'autore dell'articolo collegato a) fa essenzialmente nell'articolo, suggerisce un modo per racchiudere una fonte IO in java.util.stream.Stream. Questo è un approccio abbastanza intelligente, ma gli java.util.stream.Stream s non sono generalmente destinati a questo scopo.

Poiché non sono in genere destinati all'uso con IO, non c'è motivo per cui includere chiusura dopo le operazioni del terminale.

---

EDIT:

Dopo aver chiarito che si aveva in realtà non mescolato i due (scusate per assumendo così), grazie a this answer, ho trovato che il vostro esempio esatto si risponde nel documentation of AutoCloseable (enfasi aggiunta da me):

e 'possibile, e di fatto comune, per una classe base per implementare AutoCloseable anche se non tutte le sue sottoclassi o istanze saranno conservare risorse rilasciabili. Per il codice che deve funzionare nella generalità completa o quando è noto che l'istanza AutoCloseable richiede il rilascio di risorse, si consiglia di utilizzare le strutture try-with-resources . Tuttavia, quando si utilizzano servizi come Stream che supportano sia moduli basati su I/O che non basati su I/O, i blocchi prova con risorse non sono necessari quando si utilizzano moduli non basati su I/O.