.NET 集合和大对象堆 (LOH)答案

【问题标题】：.NET Collections and the Large Object Heap (LOH).NET 集合和大对象堆 (LOH)
【发布时间】：2010-10-16 10:29:18
【问题描述】：

具有大量项目的 .NET 集合是否易于存储在 LOH 中？

我特别对 List 和 Dictionary 感到好奇。在我的代码中，我将大量（40k+）相对较小的对象（比如说 1k）存储在临时列表和字典中以进行处理。这些集合中的项目数量是否会增加被放入 LOH 的可能性？

对于list，假设List实现为双向链表，那么元素个数应该不会增加实际List对象的大小，不过我想确定一下。

谢谢

【问题讨论】：

标签： .net memory-management collections clr

【解决方案1】：

System.Collections.Generic.List 在内部实现为数组，而不是链表。是的，如果集合的大小很大，它将被分配在大对象堆上（请注意，数组的大小很重要，如果您有一个包含大引用类型的小数组，则不会在 LOH 上分配)。

【讨论】：

【解决方案2】：

List 被实现为一个数组。因此，数组将被放入 LOH，但 List 对象本身不会。

这同样适用于字典。它也在内部使用一组存储桶，它们基本上存储您添加的键/值对。

【讨论】：

【解决方案3】：

只有超过 85,000 字节的对象才会存储在 LOH 中。一个大列表（尤其是结构）通常会在这里分配。

但是，Dictionary 不太可能，因为它们存储了一个桶数组，所以除非生成足够的桶使数组变成 >85000 字节，否则不太可能。 40k 元素的列表将存储在 LOH 中，即使它们是类（因为每个元素中的对象引用将导致列表在 x86 上为 160k，在 x64 系统上为 320k）。但是，各个元素将位于标准堆上，因此会被压缩，等等。

如果您使用双向链表而不是标准列表，则它不太可能存储在 LOH 上。列表的每个元素都很小（只有一个节点引用了下一个/上一个节点），所以没有一个对象会超过 85k 字节。

有关LOH的详细信息，this is a great blog entry.

【讨论】：

双精度数组有一个下限，因为它们在 8 字节边界上结盟时更快（与 List 一样，因为它使用数组）
Dictionary 的实现是作为一个合并的哈希表（链接，但是使用数组来存储链接的桶，以便在缓存使用方面获得开放寻址的一些优点），所以对于 40k，它们将包含一个 40000 * 的内部数组（keysize + valuesize + 8 [一个用于记忆哈希码的 int 和一个用于存储链中下一个索引的整数]）和一个 40000 * 4（int 大小）的内部数组。这 40000 实际上至少是 43627，可能多达 90523，具体取决于增长的历史，因为它使用预先计算的素数。因此，肯定会有……
... 至少一个 436270 字节的数组（如果键和值都是字节大小，则任何其他大小都更大），以及至少一个 174508 字节的索引数组。因此，一个 40k 元素的字典总是在 LOH 中有一些内部表示（字典本身更像是 40-80 字节，并且在一个代堆中，无论大小如何）。
呼应乔恩所说的。根据我的经验，字典是使用 LOH 的最大罪魁祸首之一，会导致内存碎片化。
链表的一些实现不单独分配每个节点；他们改为使用结构数组。链接不是引用，而是数组的索引。这减少了分配成本和 GC 必须处理的对象数量，即节省了 GC 的工作量。对于这样的实现，这个问题仍然存在。不过，标准的 LinkedList 不是这些实现之一。

【解决方案4】：

字典的键/值具有 O(LOG N) 向量，因此在 40K+ 个对象中您非常安全。正如之前所说的 List 被实现为数组，所以大列表确实在 LOH 上。你可以检查你是否object is on the LOH using SOS。

【讨论】：