Dois-je fermer un ByteArrayInputStream?

Petite question,

J'ai vu dans certains vieux code où un ByteArrayInputStream a été créé comme:

new BufferedReader(new InputStreamReader(new ByteArrayInputStream(somebytes)));

Et puis le BufferedReader est utilisé pour lire somebytes ligne par ligne.

Tous fonctionne bien, mais j'ai remarqué que le BufferedReader n'est jamais fermée.

C'est tout ce travail dans une longue course d'applications websphere, le somebytes sont pas terribles gros (200k plus), il n'est invoquée plusieurs fois par semaine et nous ne sommes pas confronté à l'un apparent des fuites de mémoire. Donc je pense que tous les objets sont correctement nettoyée.

J'ai toujours (une fois) appris que les flux d'entrées-sorties doivent être fermés, dans un finally déclaration. Sont ByteStreams l'exception à cette règle?

cordialement
Jeroen.

  • Merci à vous tous pour vos réponses et conseils! Comme un intervenant ci-dessous a souligné que c'était une question de RTFM ou "Avez-vous googlé?", puisque cette dernière n'a presque immédiatement révéler la réponse. Cependant, à ma connaissance, il a été volontaire à stackoverflow jusqu'à maintenant, et le bonus était les conseils de côté
InformationsquelleAutor dr jerry | 2011-02-25
  1. 44

    Vous n'avez pas à fermer ByteArrayInputStream, du moment où elle n'est pas référencé par une variable quelconque, garbage collector sortira le flux et somebytes (bien sûr en supposant qu'ils ne sont pas référencées ailleurs).

    Cependant c'est toujours une bonne habitude de fermer tous les cours d'eau, en fait, peut-être que la mise en œuvre de la création du flux qui va changer dans l'avenir et au lieu d'octets brutes vous serez la lecture du fichier? Aussi statique de code, des outils d'analyse comme PMD ou FindBugs (voir les commentaires) seront plus susceptibles de se plaindre.

    Si vous vous ennuyez avec la fermeture du flux et d'être forcé de gérer impossible IOException, vous pouvez utiliser IOUtils:

    IOUtils.closeQuietly(stream);
    • Je pense qu'il y a sans doute un peu plus impossible IOExceptions là, étant donné que le code n'est pas vraiment affaire I/O à tous!
    • findbugs est assez intelligent pour ne pas le rapport BAIS/BAOS pas être fermé.
    • Hawtin - tacklin: la beauté d'avoir vérifié exceptions 🙁
    • En fait, vous pourriez obtenir un EOF exception si utilisé d'une certaine façon, n'est-ce pas?
    • Donc, si le Flux de données/Fichier/Lecteur/WhateverIoObject est hors de portée, il est automatiquement fermé?
    • Si ByteArrayInputStream.close() ne sera jamais jeter un IOException, il n'y aurait pas de bonne raison pour ByteArrayInputStream.close() de déclarer qui est throws IOException. Bien que InputStream déclare throws, une méthode de remplacement peut jeter un sous-ensemble des exceptions de l'déclaré exceptions de la classe de base ou de l'interface. Donc, soit la Java pourraient se réserve le droit de ByteArrayInputStream.close() lancer une exception, ou ils ont fait une erreur.
    • Nous devons ajouter qu'il est de l'essayer-avec-des ressources depuis Java 7 qui résout la plupart des cas où closeQuietly-utils est venu dans maniable.
    • Comme @TomaszNurkiewicz mentionné, c'est toujours bon à fermer l'ouverture d'un ruisseau.
    • La fermeture d'un {@code ByteArrayInputStream} n'a aucun effet. Les méthodes de cette classe peut être appelée après que le flux a été fermé sans générer un {@code IOException}. À Partir De ByteArrayInputStream.java

    InformationsquelleAutor Tomasz Nurkiewicz
  2. 7

    Il est toujours une bonne pratique pour fermer vos lecteurs. Cependant pas de la fermeture d'un ByteArrayInputStream n'est pas aussi lourde d'un éventuel effet négatif parce que vous n'êtes pas accès à un fichier, il suffit d'un tableau d'octets en mémoire.

    • La documentation pour ByteArrayInputStream permettra de confirmer que close() ne fait rien. Mais c'est une bonne idée de rester dans la pratique d'appeler près sur les cours d'eau. Vous pourriez plus tard refactoriser de faire une fonction qui accepte d'autres types de flux.
    InformationsquelleAutor jzd
  3. 2

    Comme @TomaszNurkiewicz mentionné, c'est toujours bon à fermer l'ouverture d'un ruisseau. Une autre bonne façon de le laisser faire le bloc try lui-même. Essai d'utilisation de la ressource, comme....... 

    try ( InputStream inputStream = new ByteArrayInputStream(bytes); Workbook workBook = new XSSFWorkbook(inputStream)) {

    ici Classeur et InputStream à la fois met en œuvre Fermer l'Interface donc, une fois que le bloc de l'essai terminé ( normalement ou brutalement), le flux sera fermé pour sûr.

    InformationsquelleAutor KulDeep
  4. 1

    Ressources doivent être fermés dans un finally (ou l'équivalent). Mais où vous avez juste quelques octets, non, il n'a pas d'importance. Bien que lors de l'écriture, attention à flush dans le happy cas.

    • close() par la conception doit se rincer 1er.
    • N'a pas d'importance comment vous appelez flush. Pas besoin de close. Pourrait tout aussi bien être explicite.
    InformationsquelleAutor Tom Hawtin - tackline