确定多少并发操作是合适的？

在多线程编程中，确定并发操作的合适数量对于优化性能至关重要。本文讨论了影响并发操作数量的因素，包括文件大小、CPU规格和响应性要求。本文提出了一种基于工作单元的方法，其中将工作划分为独立的块，并使用通道将块分配给 Goroutine。这种方法有助于在不同平台和硬件配置上实现跨平台的可靠性能优化。

我目前正在编写一个编码器，并且（显然）希望使其更快。

我有一个用于进行编码的工作系统（因此每个 Goroutine 都在做同样的事情），但我正在努力寻找合适数量的 Goroutine 来运行代码。我基本上想决定 Goroutine 的最大数量让 CPU 保持忙碌。

我想到了以下想法：

• 如果一个文件只有 <1 kB，那么在很多 goroutine 中运行代码是没有用的
• goroutines 的数量应该受到可用核心/线程的影响
  • 在 4x4 GHz CPU 上运行 16 个 goroutine 不会有问题，但在 4x1 GHz CPU 上会怎样？
  • 很难确定可靠的跨平台
• CPU 应该很忙，但不会忙到妨碍其他程序响应（~70-ish %？）
  • 由于时钟速度和其他参数，很难提前决定

现在我尝试根据这些因素来决定使用多少个 goroutine，但我不太确定如何跨平台并以可靠的方式做到这一点。

已经做出的尝试：

• 使用线性函数根据文件大小确定
  • 根据 CPU 需要不同的功能
• 从 lscpu 解析 CPU 规格
  • 不跨平台
  • 需要另一个函数来根据频率进行确定

这并不令人满意。

解决方案

您在评论中提到

每个 goroutine 都在读取要编码的文件

但是当然，文件（任何文件）已经以某种方式编码：可能是纯文本，或者是 utf-8（字节流），可能组装成“行”单元。或者它可能是一个图像流，例如 mpeg 文件，由一定数量的帧组成。或者它可能是一个由记录组成的数据库。无论其输入形式是什么，它都包含某种可以提供给（重新）编码器的基本单元。

无论该单位是什么，都是一个合理的分工场所。 （合理程度取决于它是什么。请参阅下面分块的想法。）

假设该文件由独立的行组成：然后使用 scanner.scan 读取它们，并将每行行传递到接收行的通道。为 n 个阅读该频道的读者分拆，一次一行：

ch := make(chan string)
for i := 0; i < n; i++ {
    go readAndEncode(ch)
}

// later, or immediately:
for s := bufio.NewScanner(os.Stdin); s.Scan(); {
    ch <- s.Text()
}
close(ch)

如果有 100 行和 4 个读取器，则前四个 ch <-s.text() 操作会快速进行，第五个操作会暂停，直到其中一个读取器完成编码并返回读取通道。

如果单个行的单位太小，也许您应该一次读取一个“块”（例如 1 mb）。如果块末尾有部分行，请备份或阅读更多内容，直到获得整行。然后发送整个数据块。

因为通道复制数据，您可能希望发送对块的引用。¹对于任何较大的数据单元都是如此。 （行往往很短，与首先使用通道的开销相比，复制它们的开销通常不是很大。如果您的行的类型为 string，那么请参阅脚注。）

如果行或行块不是此处的正确工作单元，请找出是什么。将 goroutine 想象为每个人（或忙碌的小地鼠），每个人都有一项工作要做。他们可以依靠其他人（另一个人或地鼠）来完成较小的工作，无论是什么；十个人或地鼠负责子任务，这样主管就可以管理他们。如果你需要做同样的工作 n 次，并且 n 不是无限的，你可以分拆 n 个 goroutine。如果 n 可能是无限的，则分拆一个固定数量（可能基于 #cpus）并通过通道为它们提供工作。

¹正如 burak serdar 所说，某些副本可以自动删除：例如，字符串实际上是只读切片。切片类型由三部分组成：指向基础数据的指针（引用）、长度和容量。复制切片会复制这三个部分，但不会复制底层数据。字符串也是如此：字符串标头省略了容量，因此通过通道发送字符串仅复制两个标头字。因此，许多明显且易于编码的数据分块方法已经非常高效。

本篇关于《确定多少并发操作是合适的？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！