CLR 4.0 中单个对象的大小仍然限制为 2 GB？

Question

据我了解，.NET 中的单个实例有 2 GB 的限制。由于到目前为止我主要在 32 位操作系统上工作，所以我并没有对此给予太多关注。32 但无论如何这或多或少是一个人为的限制。然而，我很惊讶地得知 此限制也适用于 64 位 .NET.

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

有谁知道 CLR 4.0 中是否解决了此限制（我手头目前没有 4.0 安装）。

Answer 1

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

话虽如此，即使在 64 位系统上，单个 2GB 的引用类型数组也是一个巨大的对象数量。即使使用 8 字节引用，您也可以分配 268,435,456 个对象引用的数组 - 每个引用都可以非常大（最多 2GB，如果使用嵌套对象则更大）。这比大多数应用程序实际需要的内存还要多。

该组织的成员之一 CLR 团队在博客中介绍了这一点, ，并提供一些解决这些限制的方法选项。在 64 位系统上，执行类似 BigArray<T> 之类的操作将是一个可行的解决方案，可以将任意数量的对象分配到数组中 - 远远超过 2GB 单个对象的限制。P/Invoke 还允许您分配更大的数组。

---

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

---

编辑：.NET 4.5 现在可以在 x64 中通过设置显式允许对象大于 2GB gc允许非常大的对象 在应用程序配置中。

Answer 2

.NET框架的 4.5 允许创建阵列超过2GB在64个平台大。该特征不是在默认情况下，它必须被使用gcAllowVeryLargeObjects元件经由配置文件启用。

http://msdn.microsoft.com /en-us/library/hh285054(v=vs.110).aspx

Answer 3

这是一个大问题的数值字段中。使用数值类库在.NET有人已经他们的矩阵存储为下方阵列。这是如此的机库可以被称为做数字运算。 2GB限制严重妨碍在64位.NET可能矩阵的大小。更这里。