在 Go 中处理大数据量时使用切片而不是列表

目前golang学习网上已经有很多关于Golang的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《在 Go 中处理大数据量时使用切片而不是列表》，也希望能帮助到大家，如果阅读完后真的对你学习Golang有帮助，欢迎动动手指，评论留言并分享~

我有一个关于 Go 中切片的实用性的问题。我刚刚看到为什么在 Go 中很少使用列表？以及为什么使用数组而不是切片？但有一些问题我没有看到答案。

在我的应用程序中：

• 我读取了一个包含大约 1000 万条记录的 CSV 文件，每条记录有 23 列。
• 对于每条记录，我创建一个结构并将其放入链接列表中。
• 读取所有记录后，应用程序逻辑的其余部分将处理此链表（处理逻辑本身与此问题无关）。

我更喜欢列表而不是切片的原因是因为数组/切片需要大量的连续内存。另外，由于我不知道文件中记录的确切数量的大小，所以我无法预先指定数组大小（我知道 Go 可以根据需要动态地重新调整切片/数组的尺寸，但这看起来很糟糕）对于如此大的数据集效率很低）。

我读到的每一篇 Go 教程或文章似乎都建议我应该使用切片而不是列表（因为切片可以做列表可以做的所有事情，但以某种方式做得更好）。但是，我不明白切片如何或为什么对我的需要更有帮助？大家有什么想法吗？

正确答案

...大约 1000 万条记录，每条记录 23 列...我更喜欢列表而不是切片的原因是因为数组/切片需要大量的连续内存。

这种连续内存有其自身的优点，也有其自身的缺点。让我们考虑这两部分。

（请注意，也可以使用混合方法：块列表。但这似乎不太值得。）

此外，由于我不知道文件中记录的确切数量的大小，所以我无法预先指定数组大小（我知道 go 可以根据需要动态地重新调整切片/数组的尺寸，但是对于如此大的数据集来说，这似乎效率非常低）。

显然，如果有 n 条记录，并且您为每条记录分配并填充一次（使用列表），则时间复杂度为 o(n)。

如果您使用切片，并且每次都分配一个额外的切片条目，则从无开始，将其增长到大小 1，然后将 1 复制到大小为 2 的新数组并填充项目 #2，增长它调整为尺寸 3 并填写第 3 项，依此类推。第一个 n 实体被复制 n 次，第二个被复制 n-1 次，依此类推，对于 n (n+1)/2 = o(n²) 份。但是，如果您使用乘法扩展技术（go 的 append 实现就是这样做的），则副本数会下降到 o(log n)。不过，每个都复制更多字节。最终的结果是 o(n)，摊销（参见 Why do dynamic arrays have to geometrically increase their capacity to gain O(1) amortized push_back time complexity?）。

切片使用的空间显然是 o(n)。链表方法使用的空间也是 o(n)（尽管记录现在至少需要一个前向指针，因此每个记录需要一些额外的空间）。

因此，就构造数据所需的时间和保存数据所需的空间而言，它是 o(n)无论哪种方式。您最终会获得相同的总内存需求。无论如何，乍一看，主要区别在于链表方法不需要连续内存。

那么：使用连续内存时我们会失去什么，又会获得什么？

我们失去了什么

我们失去的东西是显而易见的。如果我们已经有了碎片化的内存区域，我们可能无法获得正确大小的连续块。也就是说，给定：

used: 1 MB (starting at base, ending at base+1M)
free: 1 MB (starting at +1M, ending at +2M)
used: 1 MB (etc)
free: 1 MB
used: 1 MB
free: 1 MB

我们总共有 6 mb，其中 3 个已使用，3 个空闲。我们可以分配 3 个 1 mb 块，但无法分配 1 个 3 mb 块，除非我们能够以某种方式压缩这三个“已使用”区域。

由于 go 程序往往在大内存空间机器上的虚拟内存中运行（虚拟大小为 64 gb 或更大），因此这往往不是一个大问题。当然，每个人的情况都不同，因此，如果您确实受到虚拟机的限制，那么这才是真正值得关注的问题。 （其他语言有压缩 gc 来处理这个问题，未来的 go 实现至少在理论上可以使用压缩 gc。）

我们得到了什么

第一个好处也很明显：我们不需要在每个记录中都有指针。这节省了一些空间——确切的数量取决于指针的大小、我们是否使用单链表等等。我们假设有 2 个 8 字节指针，或者每条记录 16 个字节。乘以 1000 万条记录，我们看起来相当不错：我们节省了 160 mb。 （go 的 container/list 实现使用双向链表，在 64 位机器上，这是所需的每个元素线程的大小。）

不过，一开始我们得到了一些不太明显的东西，而且它是巨大的。因为 go 是一种垃圾收集语言，所以每个指针都是 gc 必须在不同时间检查的东西。切片方法每条记录零个额外指针；链表方法有两个。这意味着gc系统可以避免检查不存在的2000万个指针（在1000万条记录中）。

结论

有次需要使用 container/list。如果你的算法确实需要一个列表并且这样会更清晰，那么就这样做，除非并且直到它在实践中被证明是一个问题。或者，如果您有可以位于某些列表集合中的项目（实际上是共享的项目，但其中一些在 x 列表上，一些在 y 列表上，一些在两个列表上），这需要列表样式容器。但是，如果有一种简单的方法可以将某些内容表达为列表或切片，请首先选择切片版本。由于切片内置于 go 中，因此您还可以获得第一个链接 (Why are lists used infrequently in Go?) 中提到的类型安全性/清晰度。

以上就是《在 Go 中处理大数据量时使用切片而不是列表》的详细内容，更多关于的资料请关注golang学习网公众号！