在多个线程上并行调用 ICsharpCode.SharpZipLib 是否安全

Question

我们当前使用 ICsharpCode.SharpZipLib 库的 GZipOutputStream 类进行压缩。我们通过一个线程来完成它。

我想将输入数据流分成块并并行压缩它们。 我担心这个库内部可能有一些静态数据，这些静态数据会被多个线程覆盖，从而损坏结果流。

任何想法将不胜感激。

Answer 1

这是一个非常有趣的问题。压缩是高度 CPU 密集型的，依赖于大量的搜索和比较。因此，当您拥有多个具有不受阻碍的内存访问的 CPU 时，想要并行化它是非常合适的。

DotNetZip 库中有一个名为 ParallelDeflateOutputStream 的类，它可以执行您所描述的操作。该类记录在此处。

它只能用于压缩 - 不能解压缩。而且它严格来说是一个输出流 - 您无法读取以进行压缩。考虑到这些限制，它基本上是一个 DeflateOutputStream，内部使用多个线程。

它的工作方式：它将传入流分解为块，然后将每个块放入单独的工作线程中以进行单独压缩。然后，它最后将所有这些压缩流合并回一个有序流。

假设流维护的“块”大小是 N 字节。当调用者调用 Write() 时，数据被缓冲到存储桶或块中。在 Stream.Write() 方法中，当第一个“存储桶”已满时，它会调用 ThreadPool.QueueUserWorkItem，将存储桶分配给工作项。对流的后续写入开始填充下一个存储桶，当该存储桶已满时，Stream.Write() 再次调用 QUWI。每个工作线程使用“同步”的“刷新类型”（请参阅​​ deflate 规范）压缩其存储桶，然后将其压缩的 blob 标记为准备输出。然后，这些不同的输出被重新排序（因为块 n 不一定在块 n+1 之前被压缩），并写入捕获输出流。当每个存储桶被写入时，它被标记为空，准备好由下一个 Stream.Write() 重新填充。每个块必须使用 Sync 的刷新类型进行压缩，以便允许它们通过简单的串联重新组合，使组合的字节流成为合法的 DEFLATE 流。最后的块需要Flush type = Finish。

此流的设计意味着调用者不需要使用多个线程进行写入。调用者只需像平常一样创建流，就像用于输出的普通 DeflateStream 一样，然后写入其中。流对象使用多个线程，但您的代码不直接与它们交互。 ParallelDeflateOutputStream 的“用户”代码如下所示：

using (FileStream raw = new FileStream(CompressedFile, FileMode.Create))
{
    using (FileStream input = File.OpenRead(FileToCompress))
    {
        using (var compressor = new Ionic.Zlib.ParallelDeflateOutputStream(raw))
        {
            // could tweak params of parallel deflater here
            int n;
            var buffer = new byte[8192];
            while ((n = input.Read(buffer, 0, buffer.Length)) != 0)
            {
                compressor.Write(buffer, 0, n);
            }                    
        }
    }
}

它设计用于在 DotNetZip ZipFile 类中使用，但作为独立的压缩输出流非常有用。生成的流可以用任何充气器去 DELFATED（充气？）。结果完全符合规范。

流是可调整的。您可以设置它使用的缓冲区的大小以及并行级别。它不会无限制地创建存储桶，因为对于大型流（GB 规模等），这会导致内存不足的情况。因此，存储桶的数量以及可支持的并行度都有固定的限制。

在我的双核机器上，与标准 DeflateStream 相比，该流类几乎使大型（100mb 及更大）文件的压缩速度提高了一倍。我没有更大的多核机器，所以我无法进一步测试它。代价是并行实现使用更多的 CPU 和更多的内存，并且由于我上面描述的同步帧，压缩效率也稍低（大文件减少 1%）。性能优势将根据输出流上的 I/O 吞吐量以及存储是否能跟上并行压缩器线程的速度而变化。

---

注意：
它是 DEFLATE 流，而不是 GZIP。有关差异，请阅读 RFC 1951 (DEFLATE) 和
RFC 1952 (GZIP)。

但如果您确实需要 gzip，可以使用此流的源代码，因此您可以查看它，也许可以为自己获得一些想法。 GZIP 实际上只是 DEFLATE 之上的一个包装器，带有一些附加元数据（如 Adler 校验和等 - 请参阅规范）。在我看来，构建一个 ParallelGzipOutputStream 并不是很困难，但也可能不是微不足道的。

对我来说最棘手的部分是让 Flush() 和 Close() 的语义正常工作。

---

编辑

只是为了好玩，我构建了一个 ParallelGZipOutputStream，它基本上完成了我上面描述的 GZip 操作。它使用.NET 4.0 的任务代替QUWI 来处理并行压缩。我刚刚在通过马尔可夫链引擎生成的 100mb 文本文件上进行了测试。我将该课程的结果与其他一些选项进行了比较。它看起来像这样：

uncompressed: 104857600
running 2 cycles, 6 Flavors

System.IO.Compression.GZipStream:  .NET 2.0 builtin
  compressed: 47550941
  ratio     : 54.65%
  Elapsed   : 19.22s

ICSharpCode.SharpZipLib.GZip.GZipOutputStream:  0.86.0.518
  compressed: 37894303
  ratio     : 63.86%
  Elapsed   : 36.43s

Ionic.Zlib.GZipStream:  DotNetZip v1.9.1.5, CompLevel=Default
  compressed: 37896198
  ratio     : 63.86%
  Elapsed   : 39.12s

Ionic.Zlib.GZipStream:  DotNetZip v1.9.1.5, CompLevel=BestSpeed
  compressed: 47204891
  ratio     : 54.98%
  Elapsed   : 15.19s

Ionic.Exploration.ParallelGZipOutputStream: DotNetZip v1.9.1.5, CompLevel=Default
  compressed: 39524723
  ratio     : 62.31%
  Elapsed   : 20.98s

Ionic.Exploration.ParallelGZipOutputStream:DotNetZip v1.9.1.5, CompLevel=BestSpeed
  compressed: 47937903
  ratio     : 54.28%
  Elapsed   : 9.42s

结论：

1. .NET 内置的 GZipStream 速度相当快。而且效率也不是很高，而且
   它不可调。

2. DotNetZip 中的普通（非并行化）GZipStream 上的“BestSpeed”比 .NET 内置流快大约 20%，并且提供大约相同的压缩。

3. 将普通的 DotNetZip GZipStream 与并行的进行比较，在我的双核笔记本电脑（3GB RAM）上使用多个任务进行压缩可以将所需的时间减少大约 45%。我想对于具有更多核心的机器来说，节省的时间会更多。

4. 并行 GZIP 是有成本的 - 分帧会使压缩文件的大小增加约 4%。这不会随着使用的核心数量而改变。

生成的 .gz 文件可以通过任何 GZIP 工具解压缩。

Answer 2

我的理解是 zip 正在写入（或读取）单个底层流；所以我的假设将是响亮的不；如果您谈论的是单个底层流，则这不可能是线程安全的。

然而;单独的实例与单独的底层流对话应该没问题；事实上，并行运行单独的（不相关的）任务通常比并行单个任务更容易。

Answer 3

在对类进行编码时，确保所有静态成员都是线程安全的是标准做法。所以我认为你不太可能因为这个问题而遇到问题。当然，如果您计划从不同线程使用相同 GZipOutputStream，那么这肯定会出现问题，因为该类的实例成员不是线程安全的。

您可以做的是创建一个线程安全的中间人 Stream 类（想想装饰器模式）并将其传递给 GZipOutputStream。这个自定义流类（称为 ThreadSafeStream ）本身会接受一个 Stream 实例，并使用适当的机制来同步对其的访问。

您将为每个线程创建一个 GZipOutputStream 实例，并且它们都将共享相同的 ThreadSafeStream 包装器实例。我怀疑 ThreadSafeStream 方法中可能会存在很多瓶颈，但您应该能够从中获得一些并行性。