1

In one of class, we are performing thousands of deflate format compression, decompression in concurrent threads.

Every compression/decompression is done by creating a new instance of Deflater & Inflater respectively.

I am unable to find any documentation if these classes are thread safe. Any pointers would be helpful.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
tarunkumar
  • 861
  • 2
  • 15
  • 30
  • 2
    Why do you care? I mean other than curiosity? Have you observed a problem with creating a new one each time? If not, then don't do [premature optimization](http://stackoverflow.com/q/385506/5221149). – Andreas Mar 15 '17 at 19:26

2 Answers2

1

If you look at source code, you'll find that code is synchronized, making it thread-safe.

However, synchronized means that a single Deflater/Inflator instance can only perform one operation at a time, so although it's thread-safe, it's not multi-threaded, i.e. it becomes a bottleneck if multiple threads try to use it at the same time.

So, yes, it is thread-safe, but you shouldn't share instances across threads, because it'll reduce the performance benefit of running multiple threads.

Andreas
  • 154,647
  • 11
  • 152
  • 247
  • yes I looked into code but seems like apart from synchronization, there seems to be shared state in class like byte[] buf ,ZStreamRef zsRef and so on. I am not sure if same inflator/deflator instance is used by multiple threads at same time will leads to no issue because of this shared state. – tarunkumar Mar 15 '17 at 19:47
0

You may think synchronized is the reason why these classes are thread-safe, but I want you to think about it slowly and find an answer by yourself:

java.util.zip.Deflater:

The deflater class compresses input with the deflate algorithm described in RFC 1951. It has several compression levels and three different strategies described below.

This class is not thread safe. This is inherent in the API, due to the split of deflate and setInput.

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

CONCLUSION: since compression is a raw transformation for lessen character codes values and bytes. It is not a good idea to edit the chain of bytes which are being compressed simultaneously in different (or ambiguous) processes. The output may result corrupted!.

java.util.zip.Inflater :

Inflater is used to decompress data that has been compressed according the "deflate" standard described in RFC 1950. The usage is as following. First you have to set some input with setInput(), then inflate() it. If inflate doesn't inflate any bytes there may be three reasons:

  • needsInput() returns true because the input buffer is empty. You have to provide more input with setInput().
    NOTE: needsInput() also returns true when, the stream is finished.
  • needsDictionary() returns true, you have to provide a preset dictionary with setDictionary().
  • finished() returns true, the inflater has finished.
Once the first output byte is produced, a dictionary will not needed at a later stage.

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

CONCLUSION: The fact that a big chunk of data is being decompressed means that we can take some input (tinier chunks), then apply some algorithm to output back the original data. In this case thread-safety is not obliged. Because the initial data for this class (the bytes not inflated) can remain isolated, regardless of the additional computation to be performed (call them: remove bytes, add characters, alter). After all, the big chunk of data is prepared to be decompressed as is.

1w3j
  • 566
  • 8
  • 24