Collection<T> 的最大容量与 x86 的预期不同答案

【问题标题】：Maximum capacity of Collection<T> different than expected for x86Collection<T> 的最大容量与 x86 的预期不同
【发布时间】：2014-04-02 16:10:16
【问题描述】：

关于集合（例如 List）中可以包含的最大项目数的主要问题。我在这里寻找答案，但我不明白其中的原因。

假设我们正在使用List<int> 和sizeof(int) = 4 字节...每个人似乎都确信对于x64，您最多可以有268,435,456 int，对于x86，最多可以有134,217,728 int。链接：

但是，当我自己对此进行测试时，我发现 x86 并非如此。谁能指出我可能错的地方？

//// Test engine set to `x86` for `default processor architecture`
[TestMethod]
public void TestMemory()
{
    var x = new List<int>();

    try
    {
        for (long y = 0; y < long.MaxValue; y++)
        x.Add(0);
    }
    catch (Exception)
    {
        System.Diagnostics.Debug.WriteLine("Actual capacity (int): " + x.Count);
        System.Diagnostics.Debug.WriteLine("Size of objects: " + System.Runtime.InteropServices.Marshal.SizeOf(x.First().GetType())); //// This gives us "4"
    }
}

对于 x64：268435456（预期）

对于 x86：67108864（比预期少 2 倍）

为什么人们说包含 134217728 int 的 List 正好是 512MB 内存...当您有 134217728 * sizeof(int) * 8 = 4,294,967,296 = 4GB... 什么是超过 2GB 的限制每个进程。而 67108864 * sizeof(int) * 8 = 2,147,483,648 = 2GB... 这是有道理的。

我在运行 Windows 7 8GB RAM 的 64 位机器上使用 .NET 4.5。在 x64 和 x86 中运行我的测试。

编辑：当我将容量直接设置为List<int>(134217728) 时，我得到一个System.OutOfMemoryException。

EDIT2：我的计算错误：乘以 8 是错误的，实际上是 MB =/= Mbits。我正在计算 Mbits。 67108864 个整数仍然只有 256MB...这比预期的要小。

【问题讨论】：

多少内存和哪个版本的windows？
您是否尝试过预先设置列表容量？像这样：var x = new List<int>(134217728);。请记住，内部数组是通过重新分配一个新数组来扩展的……这可能会破坏内存分配。不过，这只是一个线索，我远非专家。另外，你为什么在你的最终计算中将每个数量都乘以 8？
为什么要将大小乘以 8？如果你想以字节为单位，你不需要那个。所以 x64 上的列表大小正好是 512 MB
@LeandroTaset 不幸的是，当我直接设置容量时，我得到一个System.OutOfMemoryException。这应该是意料之中的，因为我们超过了 2GB 内存限制。
@OleksandrPshenychnyy 好地方，你是对的，我添加了一个编辑。

标签： c# .net

【解决方案1】：

List<T> 类的底层存储是T[] 数组。数组的硬性要求是进程必须能够分配连续内存块来存储数组。

这是 32 位进程中的问题。虚拟内存用于代码和数据，您可以从它们之间留下的空洞中进行分配。虽然 32 位进程将拥有 2 GB 的内存，但您永远无法接近接近该大小的孔。在您启动程序之后，您可以获得的地址空间中的最大漏洞大约是 500 或 600 兆字节。给予或接受，这在很大程度上取决于将哪些 DLL 加载到进程中。不仅是 CLR、抖动和框架程序集的本机图像，还有与托管代码无关的那种。就像反恶意软件和大量“有用”的实用程序，它们将自己蠕虫到每个进程中，比如 Dropbox 和 shell 扩展。一个基础差的人可以在两个小洞中挖出一个很好的大洞。

随着程序分配和释放内存一段时间，这些漏洞也会变小。一个普遍的问题称为地址空间碎片。一个长时间运行的进程在分配 90 MB 时可能会失败，即使周围有大量未使用的内存。

您可以使用 SysInternals 的VMMap utility 获得更多洞察。通常还需要一份 Russinovich 的《Windows Internals》一书，以了解您所看到的内容。

【讨论】：

+1 - 查看内存映射是理解问题的正确方法。
很好的答案。我确保我没有加载任何额外的 DLL，并确保没有其他任何东西正在执行但该代码......看起来测试引擎中有一些额外的东西。现在最大容量表示为 134,217,728 int。非常感谢，很有道理。

【解决方案2】：

这可能也有帮助，但我能够通过使用提供的代码创建一个测试项目来复制这个 67108864 限制

在控制台、winform、wpf 中，我能够获得134217728 限制

在 asp.net 中我得到了33554432 限制

所以在你的一条评论中你说[TestMethod]，这似乎是问题所在。

【讨论】：

确实，这似乎是问题所在。汉斯的回答也让我得出了这个结论。

【解决方案3】：

虽然您可以拥有 MaxValue 项，但实际上您会在此之前耗尽内存。

以 x86 运行，即使在 x46 机器上，最大内存也可能是 4GB，如果在 x86 版本的 Windows 上，最大可能是 2GB 或 3GB。

可用内存很可能要小得多，因为您只能为数组分配最大的连续空间。

【讨论】：