.net - 在 CLR 4.0 中，单个对象的大小仍限制为 2 GB？

Question

据我了解，.NET 中的单个实例有 2 GB 的限制。因为到目前为止我主要在 32 位操作系统上工作，所以我没有对此给予太多关注。在 32 上，但这或多或少是人为的限制。然而，我很惊讶地得知 this limitation also applies on 64 bit .NET .

自从 List<T> 等收藏使用数组来存储项目，这意味着在 32 位上运行的 .NET 应用程序将能够在列表中保存两倍于在 64 位上运行的相同应用程序的引用类型项目。这在我看来是相当令人惊讶的。

有谁知道 CLR 4.0 中是否解决了这个限制(我目前没有 4.0 安装)。

Answer 1

比这更糟糕 - 你是进程空间，当你在 32 位的 .NET 中工作时，它远小于理论限制。在 32 位 .NET 应用程序中，我的经验是，您总是会在 1.2-1.4gb 内存使用量左右开始出现内存不足错误(有些人说他们可以达到 1.6...但我从未见过)。当然，这在 64 位系统上不是问题。

话虽如此，一个 2GB 的引用类型数组，即使在 64 位系统上，也是一个庞大的对象数量。即使使用 8 字节引用，您也可以分配一个包含 268,435,456 个对象引用的数组——每个引用都可以非常大(最多 2GB，如果它们使用嵌套对象则更多)。这比大多数应用程序真正需要的内存要多。

CLR team blogged about this 的成员之一，有一些解决这些限制的方法的选项。在 64 位系统上，执行 BigArray 之类的操作将是一种可行的解决方案，可以将任意数量的对象分配到一个数组中——远远超过 2gb 的单个对象限制。 P/Invoke 也可以让你分配更大的数组。

---

编辑:我也应该提到这一点 - 我认为 .NET 4 的这种行为根本没有改变。自 .NET 开始以来，这种行为一直没有改变。

---

编辑:.NET 4.5 现在可以在 x64 中通过在 app.config 中设置 gcAllowVeryLargeObjects 来明确允许对象大于 2gb。