我想编写一个使用NET 3.5和GZipStream库执行多线程压缩/解压缩的程序。
输入文件非常大（比方说数百GB）
我想在没有任何中间文件的情况下实现这一目标。这是我最初的方法，但要求已更改。
我正在考虑以下方法，并想验证一下它在纸上看起来是否不错：
从源文件读取并将其拆分为内存中恒定大小的块。
由于内存有限，请跟踪线程数。
每个块由单独的线程压缩在内存中。
这些压缩的块按正确的顺序放入队列。
有一个线程从队列中读取并将其连接到输出文件中。
还将一些与压缩块有关的元数据存储在某个地方，稍后将将其放入标头中。我想用它来减压。
完成上述操作后，我对多线程解压缩的想法将是：
读取有关串联块的元数据文件。
从压缩文件中读取由元数据定义的块中的数据。
每个块由内存中的单独线程解压缩。
这些解压缩的块将以适当的顺序添加到队列中。
有一个线程将解压缩的块连接成一个统一的输出文件。
以上似乎合理吗？
当然可以。碰巧的是，有效gzip文件的串联也是有效gzip文件。每个不同的可解压缩流称为gzip成员。您的元数据只需要文件中每个流开始处的偏移量即可。
gzip标头的额外块限制为64K字节，因此这可能会限制块的大小，例如，几十到一百兆字节。出于另一个原因，我建议您压缩的数据块至少应至少为几兆字节-以避免降低压缩效率。
串联的一个缺点是您无法全面检查输入的完整性。例如，如果您以某种方式弄乱了成员的顺序，那么在解压缩时将不会检测到该顺序，因为每个成员的完整性检查都会通过，而与顺序无关。因此，您可能需要对未压缩的数据进行全面检查。一个示例是整个未压缩数据的CRC，可以使用zlib's从成员的CRC计算得出crc32_combine()。
我想知道您是否从并行解压缩中获得了显着的加速。解压缩通常足够快，以至于它在要读取的大容量存储设备上受I / O约束。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句