Are ZipFile InputStreams thread safe?

Question

I cannot find any statement that specifies whether it would be safe to get multiple InputStreams (from multiple ZipEntry's) and process each in its own thread.

Would this be safe to attempt?

Would it be advisable?

Added

Might I get better performance this way?

Answer 1

Reading should be OK. Each stream contains its own state, so you can open multiple streams that point to the same file and read from them concurrently.

But simultaneous writing is wrong. It will create mismatch in your file.

Answer 2

ZipFile InputStreams should be threadsafe, but the ZipFile API itself is instance-synchronized (internally all the reading/writing methods, including for reading metadata, are isolated using synchronized (this)), so ZipFile instances can be accessed by only one thread at a time.

If you want multiple threads to read from the same zipfile in a scalable way, you must open one ZipFile instance per thread, with each thread reading from separate InputStreams, each one derived from a different ZipEntry. That way, the per-thread lock in the ZipFile methods does not block all but one thread from reading from the zipfile at one time. It also means that when each thread closes the ZipFile after they're done reading, they close their own instance, not the shared instance, so you don't get an exception on the second and subsequent close.

Protip: if you really care about speed, and you need multiple threads reading from the same ZipFile, you can get more performance by reading all the ZipEntry objects from the first ZipFile instance, and sharing them with all threads, to avoid duplicating work in reading the zipfile central directory for each thread separately. A ZipEntry object is not tied to a specific ZipFile instance per se, ZipEntry just records metadata that will work with any ZipFile object representing the same zipfile that the ZipEntry came from. So this is the recipe for scaling up ZipFile usage in Java:

1. Open N ZipFile instances on the file, one for each of the N worker threads.
2. For just one of the ZipFile instances, read all the ZipEntry objects, and store in a list.
3. Distribute the list of ZipEntry objects to each of the N worker threads, along with the thread's own unique ZipFile instance.
4. In parallel, within each thread, open an InputStream on the thread's ZipFile instance, using whatever ZipEntry objects you want that thread to open (e.g. you could instruct each thread to open just one of the files). Or you could put all the ZipEntry objects into a concurrent queue or parallel stream, and all the worker threads could consume entries from the queue, if you want just one thread to open each ZipEntry, while load-leveling as well as possible.
5. When each thread has finished, it should close its own ZipFile instance.