在其中一个类中，我们正在执行数千个deflate格式压缩，并发线程中的解压缩。
每次压缩/解压缩都是通过创建Deflater＆amp;的新实例来完成的。 Inflater分别。
如果这些类是线程安全的，我无法找到任何文档。任何指针都会有所帮助。
答案 0 :(得分：1)
如果查看源代码，您会发现代码为synchronized，使其成为线程安全的。
但是，synchronized表示单个Deflater / Inflator实例一次只能执行一个操作，因此虽然它是线程安全的，但它不是多线程的，即它如果多个线程试图同时使用它，则会成为瓶颈。
所以，是的，它是线程安全的，但你不应该跨线程共享实例，因为它会降低运行多个线程的性能优势。
答案 1 :(得分：0)
您可能认为synchronized是这些类是线程安全的原因，但我希望您慢慢思考它并自己找到答案：
java.util.zip.Deflater：
deflater class 使用RFC 1951中描述的deflate算法压缩输入。它有几个压缩级别和下面描述的三种不同策略。
此类不线程安全。这是API中固有的，由于deflate和setInput的分离。
源代码：http://developer.classpath.org/doc/java/util/zip/Deflater-source.html
结论：因为压缩是减少字符代码值和字节的原始转换。 编辑在不同（或模糊）进程中同时压缩的字节链不是一个好主意。输出可能会导致损坏！。
java.util.zip.Inflater：
Inflater用于解压缩根据RFC 1950中描述的“deflate”标准压缩的数据。用法是 如下。首先，你必须设置一些输入
setInput()，然后膨胀（）它。 如果膨胀没有膨胀任何字节，可能有三个原因：生成第一个输出字节后，将不再需要字典。
- needsInput（）返回true ，因为输入缓冲区为空。您必须使用
setInput()提供更多输入 注意：在流完成时，needsInput（）也返回true。- needsDictionary（）返回true，您必须提供带
setDictionary()的预设字典。- finished（）返回true，inflater已完成。
源代码：http://developer.classpath.org/doc/java/util/zip/Inflater-source.html
结论：大量数据被解压缩的事实意味着我们可以采取一些输入（更小的块），然后应用一些算法输出回来原始数据。在这种情况下，线程安全没有义务。因为此类的初始数据（未充气的字节）可以保持隔离，无论要执行的其他计算如何（调用它们：删除字节，添加字符，更改）。毕竟，大块数据准备按原样解压缩。