c# - Collection 的最大容量与 x86 的预期不同

Question

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

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

• List size limitation in C#
• Where is the maximum capacity of a C# Collection<T> defined?
• What's the max items in a List<T>?

但是，当我自己对此进行测试时，我发现 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 的列表恰好是 512MB 的内存...当您有 134217728 * sizeof(int) * 8 = 4,294,967,296 = 4GB 时...每个进程超过 2GB 的限制是什么.而 67108864 * sizeof(int) * 8 = 2,147,483,648 = 2GB...这是有道理的。

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

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

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

Answer 1

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

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

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

您可以使用 SysInternals 的 VMMap utility以获得更多的洞察力。阅读 Russinovich 的《Windows 内部原理》一书通常也是必要的，这样才能理解您所看到的内容。