我被分配在 Java 7 中并行化 GZip,但我不确定哪个是可能的。
作业是:
我尝试过的:
我不确定我的方法是错误的还是完全采取了错误的方法。谁能指出我在这个项目中使用哪些类的正确方向?
是的,用字典压缩文件不能并行,因为一切都取决于一切。也许您的老师要求您并行化文件夹中多个文件的单独 gzip 压缩?这将是并行工作的一个很好的例子。
我认为你可以通过在压缩流中插入适当的重置来做到这一点。这个想法是,gzip 中使用的底层压缩引擎允许重置deflater,目的是更容易从流损坏中恢复,尽管代价是使压缩比变得更糟。重置后,压缩器将处于已知状态,因此您实际上可以在多个线程(当然,从输入数据中的许多位置)中从该状态(独立于被压缩的内容)开始生成压缩的块并包含执行以下重置时生成的数据,以便将放气器恢复到已知状态。然后您只需将压缩片段重新组装成整个压缩流。 “简单的!” (哈!)
我不知道这是否可行,而且我怀疑整个事情的复杂性将使其不是一个可行的选择,除非您压缩单个非常大的文件。 (如果您有很多文件,那么并行压缩每个文件会更容易。)不过,这就是我首先尝试的。 (另请注意,gzip 格式只是带有额外元数据的压缩流。)
同时进行压缩的唯一方法是更改算法(使其与现有方法不兼容)
并行 gzip 编码器可以处理自己的 1MB 输入,并将其 gzip 成员不可预测的输出长度在目标文件中一个接一个地串联起来,因为 gzip 文件被设计为 1..n 个 gzip 成员的串联。
为了以 gzip 格式嵌入压缩块,压缩器使用 nowrap==true (无 zlib 标头)。这里有一个关键细节:如果不添加 deflate 标头,则“预设字典”标志和 DICTID 无法通信。因此,没有办法向充气机提供有关(更不用说传递)字典的建议。
为了能够在充气之前在每个充气机上注入最后 32kb 字典,需要自定义参数化和行为,而这在 gzip rfc 中是没有的。因此,如果最终格式预计符合 gzip rfc 标准,我认为那些 32kB 字典没有任何意义。