据我了解，.NET 中的单个实例有 2 GB 的限制。因为到目前为止我主要在 32 位操作系统上工作，所以我没有对此给予太多关注。在 32 上，但这或多或少是人为的限制。但是，当我得知此限制也适用于 64 位 .NET 时，我感到非常惊讶。
由于诸如List<T>使用数组来存储项目之类的集合，这意味着在 32 位上运行的 .NET 应用程序将能够在列表中保存两倍于在 64 位上运行的相同应用程序的引用类型项目。这是相当令人惊讶的 imo。
有谁知道 CLR 4.0 中是否解决了这个限制（我目前没有 4.0 安装）。
比这更糟糕 - 你是进程空间，当你在 32 位的 .NET 中工作时，它远小于理论限制。在 32 位 .NET 应用程序中，我的经验是，您总是会在 1.2-1.4gb 内存使用量左右开始出现内存不足错误（有些人说他们可以达到 1.6...但我从未见过）。当然，这在 64 位系统上不是问题。
话虽如此，一个 2GB 的引用类型数组，即使在 64 位系统上，也是大量的对象。即使使用 8 字节引用，您也可以分配一个包含 268,435,456 个对象引用的数组——每个引用都可以非常大（最多 2GB，如果它们使用嵌套对象则更多）。这比大多数应用程序真正需要的内存要多。
CLR 团队的一位成员对此发表了博文，并提供了一些解决这些限制的方法的选项。在 64 位系统上，执行 BigArray<T> 之类的操作将是一个可行的解决方案，可以将任意数量的对象分配到一个数组中——远远超过 2gb 的单个对象限制。P/Invoke 也允许您分配更大的数组。
编辑：我也应该提到这一点 - 我不相信这种行为对于 .NET 4 来说根本没有改变。自 .NET 开始以来，这种行为一直没有改变。
编辑：.NET 4.5 现在可以在 x64 中通过在 app.config 中设置gcAllowVeryLargeObjects来明确允许对象大于2gb。
.NET Framework 4.5允许在 64 位平台上创建大于 2GB 的数组。此功能默认不启用，必须通过配置文件使用 gcAllowVeryLargeObjects 元素启用。
http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx
这在数值领域是一件大事。在 .NET 中使用数值类库的任何人都将其矩阵存储为下面的数组。这样就可以调用本机库来进行数字运算。2GB 的限制严重阻碍了 64 位 .NET 中可能的矩阵大小。更多在这里。