Ich lese den Code von jemand anderem. Hier ist der Kern davon.
Eine Klasse komprimiert und dekomprimiert Dateien mit GZIPInputStream und GZIPOutputStream.
Hier ist ein Ausschnitt dessen, was während der Komprimierung abläuft. inputFile und outputFile sind Instanzen der Klasse File .
Nun, hier ist was während der Dekompression passiert.
%Vor% Was ist ein möglicher Grund, warum der ursprüngliche Programmierer FileOutputStream während der Komprimierung und ByteArrayOutputStream während der Dekomprimierung gewählt hat? Das verwirrt mich.
Wenn es keinen guten Grund gibt, denke ich, dass ich sie ändern werde, um eine zukünftige Verwirrung zu vermeiden. Ist das eine gute Idee?
Heh, klingt, als hätten sie Code aus verschiedenen Quellen kopiert und eingefügt? :-P Nein, ernsthaft, wenn Sie die dekomprimierten Daten nicht untersuchen müssen, können Sie einfach ein BufferedOutputStream für die Komprimierung und Dekomprimierung verwenden.
Das ByteArrayOutputStream ist mehr Speicherbedarf, da es den gesamten Inhalt im Java-Speicher ablegt (im Stil von byte[] ). Das FileOutputStream schreibt direkt auf die Festplatte und ist daher weniger Speicher. Ich sehe keinen vernünftigen Grund, ByteArrayOutputStream in diesem speziellen Fall zu verwenden. Es modifiziert die einzelnen Bytes danach nicht. Es wird nur unverändert in die Datei geschrieben. Es ist somit ein unnötiger Zwischenschritt.
Der Programmierer hat während der Komprimierung FileInputStream verwendet und beim Dekomprimieren Puffer verwendet. Ich denke, dass der Grund dafür war, dass nichts Schlimmes passiert, wenn du versuchst, die Datei zu lesen. Sie scheitern einfach und eine Ausnahme wird ausgelöst.
Wenn Sie beim Dekomprimieren versagen und bereits mit dem Schreiben in die Datei begonnen haben, ist die Datei beschädigt. Also entschied er sich, zuerst den Puffer zu schreiben und dann, wenn die Dekomprimierung abgeschlossen ist, den Puffer auf der Festplatte zu schreiben. Diese Lösung ist in Ordnung, wenn Sie mit relativ kleinen Dateien arbeiten. Sonst erfordert dies viel Speicher und könnte OutOfMemeoryError erzeugen.
Ich würde zip direkt in die temporäre Datei extrahieren und dann die temporäre Datei in ihren permanenten Namen umbenennen. Abschließend sollte Block darauf achten, die temporäre Datei zu löschen.