我有一个关于Go中切片的实用性的问题。我刚刚看到为什么Go中很少使用列表？为什么使用数组而不是切片？但是我有一些问题没有得到回答。
在我的应用程序中：
- 我读到一个CSV文件，其中包含大约1000万条记录，每条记录有23列
- 对于每条记录，我创建一个结构并将其放入一个链表中
- 一旦读取了所有记录，应用程序逻辑的其余部分就可以使用这个链表(处理逻辑本身与这个问题无关)
我喜欢列表而不是切片的原因是数组/切片需要大量的连续内存。此外，由于我不知道文件中记录的确切数量的大小，我无法提前指定数组大小(我知道Go可以根据需要动态地重新确定切片/数组的大小，但对于如此大的数据集来说，这似乎效率非常低)。
我读到的每一篇Go教程或文章似乎都建议我应该使用切片而不是列表(因为切片可以做列表所能做的一切，但在某种程度上做得更好)。然而，我不明白切片如何或为什么会对我的需求更有帮助？有人有什么想法吗？
。。。大约1000万条记录，每条记录有23列。。。我喜欢列表而不是切片的原因是数组/切片需要大量的连续内存。
这种连续内存既有优点，也有缺点。让我们同时考虑这两部分。
(注意，也可以使用混合方法：块列表。不过，这在这里似乎不太值得。)
此外，由于我不知道文件中记录的确切数量的大小，因此我无法提前指定数组大小(我知道Go可以根据需要动态地重新确定切片/数组的大小，但对于如此大的数据集来说，这似乎效率非常低)。
很明显，如果有n个记录，并且您分配并填写每个记录一次(使用列表)，则这是O(n)。
如果您使用一个切片，并且每次都分配一个额外的切片条目，则从零开始，将其扩展到1大小，然后将1复制到2大小的新数组并填充项目#2，将其增长到3大小并填充项目#3，依此类推。n个实体中的第一个被复制n次，第二个被复制<1次，依此类推，对于n(n+1)/2＝O(n2)个拷贝。但是，如果您使用乘法扩展技术——Go的append实现就是这样做的——这将减少到O(logn)个副本。不过，每一个都会复制更多的字节。它最终是O(n)，摊销(请参阅为什么动态阵列必须以几何方式增加它们的容量才能获得O(1)摊销的推回时间复杂性？)。
与切片一起使用的空间显然是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个1MB块，但我们不能分配一个3MB块，除非我们能够以某种方式压缩三个"块"；使用"；区域。
由于Go程序往往在大内存空间机器(虚拟大小为64GB或更大)的虚拟内存中运行，因此这往往不是什么大问题。当然，每个人的情况都不一样，所以如果你真的受到虚拟机的约束，那真的是一个令人担忧的问题。(其他语言有压缩GC来处理这个问题，未来的Go实现至少在理论上可以使用压缩GC。)
我们获得了什么
第一个好处也是显而易见的：我们不需要在每条记录中都有指针。这节省了一些空间——确切的数量取决于指针的大小，我们是否使用单链表等等。我们假设2个8字节的指针，或者每个记录16字节。乘以1000万条记录，我们在这里看起来相当不错：我们节省了160兆字节。(Go的container/list实现使用双链表，在64位机器上，这是所需的每个元素线程的大小。)
不过，一开始我们得到了一些不太明显的东西，而且它是巨大的。因为Go是一种垃圾收集语言，所以GC必须在不同的时间检查每个指针切片方法每个记录有零个额外的指针；链表方法有两个。这意味着GC系统可以避免检查不存在的2000万个指针(在1000万条记录中)。
结论
有次使用container/list。如果你的算法真的需要一个列表，并且这样做明显更清晰，那么就这样做，除非它在实践中被证明是一个问题。或者，如果您有一些项目可以在某个列表集合中——这些项目实际上是共享的，但其中一些在X列表上，一些在Y列表上，还有一些在两者上——这就需要一个列表样式容器。但是，如果有一种简单的方法可以将某个东西表示为列表或切片，请先选择切片版本。因为切片是在Go中构建的，所以您还可以获得第一个链接中提到的类型安全性/清晰度(为什么Go中很少使用列表？)。