java.util.zip - ZipInputStream v. s. ZipFile

Habe ich einige Allgemeine Fragen bezüglich der java.util.zip Bibliothek.
Was wir im Grunde tun, ist eine import-und eine export-von vielen kleinen Komponenten. Bereits diese Komponenten wurden importiert und exportiert, mit einer einzigen großen Datei, z.B.:

<component-type-a id="1"/>
<component-type-a id="2"/>
<component-type-a id="N"/>

<component-type-b id="1"/>
<component-type-b id="2"/>
<component-type-b id="N"/>

Bitte beachten Sie, dass die Reihenfolge der Komponenten beim import relevant ist.

Nun jede Komponente einnehmen soll seine eigene Datei, die sollte extern versioniert, QA-ed, bla, bla. Wir beschlossen, dass die Ausgabe von export-sollten Sie eine zip-Datei (mit all diesen Dateien in) und den input unserer import sollte eine ähnliche zip-Datei. Wir wollen nicht explodieren, die zip-in unserem system. Wir wollen nicht öffnen separate streams für die einzelnen kleinen Dateien. Meine aktuellen Fragen:

Q1. Kann die ZipInputStream garantieren, dass die zip-Einträge (kleine Dateien) gelesen werden, in der gleichen Reihenfolge, in der Sie eingefügt wurden, durch unsere export verwendet ZipOutputStream? Ich nehme an, das Lesen ist so etwas wie:


ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
ZipEntry entry;
while((entry = zis.getNextEntry()) != null) 
{
       //read from zis until available
}

Ich weiß, dass die zentrale zip-Verzeichnis wird auf das Ende der zip-Datei aber trotzdem die Einträge in der Datei drinnen haben sequenzieller Reihenfolge. Ich weiß auch, dass das Vertrauen auf die Reihenfolge ist eine hässliche Vorstellung, aber ich möchte einfach alle Fakten im Kopf.

Q2. Wenn ich ZipFile (was ich bevorzuge) was ist die Auswirkung auf die performance von Aufruf getInputStream() Hunderte Male? Wird es langsamer sein, als die ZipInputStream Lösung? Die zip ist nur einmal geöffnet und ZipFile ist gesichert durch RandomAccessFile - ist das richtig?
Ich nehme an, das Lesen ist so etwas wie:


ZipFile zipfile = new ZipFile(argv[0]);
Enumeration e = zipfile.entries();//TODO: assure the order of the entries
while(e.hasMoreElements()) {
        entry = (ZipEntry) e.nextElement();
        is = zipfile.getInputStream(entry));
}

Q3. Sind die input-streams werden aus der gleichen ZipFile thread-sicher (z.B. kann ich Las verschiedene Einträge in verschiedenen threads gleichzeitig)? Irgendwelche Leistungseinbußen?

Dank für Eure Antworten!

InformationsquelleAutor Lachezar Balev | 2011-01-11

io java thread-safety zip

4

Q1: ja, Bestellung wird der gleiche sein, in denen die Einträge wurden Hinzugefügt.

Q2: beachten Sie, dass aufgrund der Struktur des zip-Archiv-Dateien und Komprimierung, keine der Lösungen ist genau streaming; Sie alle tun das einige Niveau der Pufferung. Und wenn Sie check out JDK-Quellen, Implementierungen teilen die meisten code. Es gibt keine echten random-access -, content, obwohl der index nicht lassen Sie finden Stücke, die entsprechen Einträge. Also ich denke, es sollte nicht sein, aussagekräftige performance-Unterschiede; vor allem, OS tun werden, die Zwischenspeicherung von disk-Blöcken sowieso. Möchten Sie vielleicht nur die Testleistung zu überprüfen, ob dies mit einem einfachen Testfall.

Q3: ich würde nicht zählen auf diese; und wahrscheinlich sind Sie nicht. Wenn Sie wirklich, dass der gleichzeitige Zugriff helfen würde (vor allem, weil die Dekompression ist die CPU gebunden, so dass es helfen könnte), würde ich versuchen, Lesen die gesamte Datei in den Arbeitsspeicher, setzen über ByteArrayInputStream und Konstrukt mehrere unabhängige Leser.

Hi StaxMan! Ich war nur die überprüfung der Umsetzung der ZipFile$ZipFileInputStream in JDK6. Dies wird zurückgegeben, von Zipfiles.getInputStream Es hat die Synchronisierung obwohl ich wirklich nicht weiß, wie zuverlässig ist das.
Ja, ich kann nicht sicher sagen, es ist nicht thread-safe. Eine weitere gefährliche Teil ist das zugrundeliegende native zlib-Bibliothek, die ich vermute, ist nicht thread-safe.
Kann ich bezeugen die Tatsache, dass es nicht threadsicher sind, durch schmerzhafte Erfahrung.

InformationsquelleAutor StaxMan

Ich gemessen, dass nur die Auflistung der Dateien mit ZipInputStream ist 8 mal langsamer als mit ZipFile.

    long t = System.nanoTime();
    ZipFile zip = new ZipFile(jarFile);
    Enumeration<? extends ZipEntry> entries = zip.entries();
    while (entries.hasMoreElements())
    {
        ZipEntry entry = entries.nextElement();

        String filename = entry.getName();
        if (!filename.startsWith(JAR_TEXTURE_PATH))
            continue;

        textureFiles.add(filename);
    }
    zip.close();
    System.out.println((System.nanoTime() - t) / 1e9);

und

    long t = System.nanoTime();
    ZipInputStream zip = new ZipInputStream(new FileInputStream(jarFile));
    ZipEntry entry;
    while ((entry = zip.getNextEntry()) != null)
    {
        String filename = entry.getName();
        if (!filename.startsWith(JAR_TEXTURE_PATH))
            continue;

        textureFiles.add(filename);
    }
    zip.close();
    System.out.println((System.nanoTime() - t) / 1e9);

(Don ' T führen Sie Sie in die gleiche Klasse. Machen Sie zwei verschiedenen Klassen und führen Sie diese separat)

Meine Vermutung ist, ZipFile ist das Lesen der zip-index während ZipInputStream ist "Durchschleifen" die gesamte zip-Datei Lesen eine Datei nach der anderen, FWIW.

InformationsquelleAutor Mark Jeronimus

0

Bezüglich Q3, Erfahrung in JENKINS-14362 deutet darauf hin, dass die zlib ist nicht thread-safe auch beim Betrieb auf unabhängigen streams, d.h., dass es einige falsch geteilt statischen Zustand. Nicht bewiesen, nur eine Warnung.

InformationsquelleAutor Jesse Glick

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.