Mi chiedevo se è necessario poiché quando utilizzo questo metodo, il file viene letto dal classpath. "Non chiudendo" porta a una perdita di memoria.dovrebbe essere chiuso Class.getResourceAstream?
Come posso verificare tali perdite di memoria?
Si presume che Class.getResourceAsStream() restituirà sempre un flusso che punta a un file all'interno del file JAR della classe. Questo non è corretto Il classpath può contenere anche cartelle, nel qual caso Class.getResourceAsStream() restituirà un FileInputStream. Alcuni altri programmi di caricamento classe potrebbero anche restituire altri tipi di risorse, come i file remoti (nel caso di un URLClassLoader).
Anche nel caso di un file JAR, è possibile che l'implementazione mantenga, con qualsiasi mezzo, una vista persistente all'interno del file JAR ai byte compressi del file a cui si sta accedendo. Forse è in possesso di una memoria mappata ByteBuffer ...
Perché cogliere l'occasione? Dovresti sempre chiudere i flussi (e qualsiasi altro Closeable, actualy), indipendentemente da come ti sono stati dati.
Per quanto riguarda l'individuazione di perdite, la strategia migliore consiste nell'ottenere un dump della memoria nel momento in cui la macchina virtuale viene arrestata, quindi analizzarla con qualche strumento. Due strumenti popolari sono jhat e Eclipse mat.
Il tipo restituito è un inputstream quindi, indipendentemente dall'implementazione concreta (che potrebbe cambiare da versione a versione), si dispone di un metodo close() che deve essere chiamato imho.
Non importa se quel metodo sta effettivamente facendo qualcosa di utile con la versione corrente.
Come regola generale è necessario chiudere tutti i flussi (e altri tipi che forniscono funzionalità ravvicinate). Può portare a perdite di risorse ro (la memoria è un tipo di risorsa).
Sebbene sia presente una garbage collection automatica che recupera la memoria alla fine quando un oggetto non viene più riferito, potrebbe comunque contenere risorse native che potrebbero non essere rilasciate. Inoltre, se un altro oggetto di lunga durata (ad esempio il classloader) mantiene una presa sulla risorsa, non verrà rivendicato dal garbage collector.
Se il programma è di breve durata, o si apre solo un numero limitato di risorse, è possibile che non si verifichino problemi, ma le perdite di risorse sono difficili da rilevare nelle applicazioni di lunga durata.