Sind java.util.zip.Deflater & java.util.zip.InFlater Klassen thread sicher

Question

In einer der Klassen, führen wir Tausende von Deflate-Format-Komprimierung, Dekomprimierung in parallelen Threads.

Jede Komprimierung/Dekomprimierung erfolgt durch Erstellen einer neuen Instanz von Deflater & Inflater.

Ich kann keine Dokumentation finden, wenn diese Klassen threadsicher sind. Alle Hinweise wären hilfreich.

Answer 1

Sie mögen denken, synchronized ist der Grund, warum diese Klassen Thread-sicher sind, aber ich möchte Sie darüber langsam denken und eine Antwort selbst finden:

java.util.zip.Deflater:

Die deflater Klasse komprimiert Eingabe mit dem Deflate-Algorithmus beschrieben in RFC 1951. Es hat mehrere Komprimierungsstufen und drei verschiedene Strategien, die unten beschrieben werden.

Diese Klasse ist nicht Thread sicher. Dies ist in der API, aufgrund der Aufteilung von deflate und setInput inhärent.

Quellcode: http://developer.classpath.org/doc/java/util/zip/Deflater-source.html

FAZIT: seit Kompression ist eine rohe Transformation für verringern Zeichencodes Werte und Bytes. Es ist keine gute Idee zu bearbeiten die Kette von Bytes, die gleichzeitig in verschiedenen (oder mehrdeutigen) Prozessen komprimiert werden. Die Ausgabe kann beschädigt werden.

java.util.zip.Inflater:

Inflater zu dekomprimieren Daten verwendet wird, die den "entlüften" Standard beschrieben in RFC komprimiert wurde nach 1950. Die Verwendung wie folgend. Zuerst müssen Sie einige Eingaben mit setInput() vornehmen und dann() aufblasen. Wenn das Feld "Inflation" keine Bytes aufbläht, kann dies drei Ursachen haben:

• needsInput() gibt den Wert zurück, da der Eingabepuffer leer ist. Sie müssen mehr Eingaben mit setInput() bereitstellen.
  HINWEIS: needsInput() gibt auch true zurück, wenn der Stream beendet ist.
• needsDictionary() gibt true zurück, Sie müssen ein voreingestelltes Wörterbuch mit setDictionary() bereitstellen.
• Fertig() gibt True zurück, der Inflator ist fertig.

Sobald das erste Ausgabebyte erzeugt wurde, wird zu einem späteren Zeitpunkt kein Wörterbuch mehr benötigt.

Quellcode: http://developer.classpath.org/doc/java/util/zip/Inflater-source.html

FAZIT: Die Tatsache, dass ein großer Teil der Daten bedeutet dekomprimiert ist, dass wir eine Eingabe (winzige chunks) nehmen können, dann einige Algorithmus gelten gib die Originaldaten zurück. In diesem Fall ist Thread-Sicherheit nicht verpflichtet. Weil die Anfangsdaten für diese Klasse (die nicht aufgeblähten Bytes) isoliert bleiben können, unabhängig von der zusätzlich durchzuführenden Berechnung (sie aufrufen: Bytes entfernen, Zeichen hinzufügen, ändern). Schließlich ist der große Datenblock bereit, so wie er ist zu dekomprimieren.

Answer 2

Wenn Sie sich den Quellcode ansehen, werden Sie feststellen, dass der Code synchronized ist, was ihn threadsicher macht.

jedoch synchronized bedeutet, dass eine einzelne Deflater/Inflator Instanz nur eine Operation zu einem Zeitpunkt durchführen kann, so dass, obwohl es threadsicher ist, ist es nicht multi-threaded, dh es ist ein Engpass wird, wenn mehrere Threads versuchen, es zu verwenden, um die selbe Zeit.

Also ja, es ist Thread-sicher, aber Sie sollten Instanzen nicht über Threads teilen, weil es den Leistungsvorteil der Ausführung mehrerer Threads reduzieren wird.