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

据我了解，在.NET中的单个实例有2 GB的限制。由于我迄今为止主要在32位操作系统上工作，所以我没有付出太多的关注。在32上，反正它或多或less是一个人为的限制。不过，我很惊讶地发现这个限制也适用于64位.NET 。

由于List<T>等集合使用数组来存储项目，这意味着运行在32位上的.NET应用程序与在64位上运行的相同应用程序相比，能够在列表中容纳两倍的引用types项目。这是令人惊讶的IMO。

有谁知道这个限制是否在CLR 4.0中解决（我目前没有安装4.0版本）。

它比这更糟 – 当你在32位.NET中工作时，你是进程空间，远小于理论极限。在32位的.NET应用程序中，我的经验是，你总是会倾向于在大约1.2-1.4GB的内存使用量的地方出现内存错误（有些人说他们可以达到1.6 …但是我从来没有见过）。当然，这在64位系统上不是问题。

也就是说，即使在64位系统上，一个2GB的引用types的数组也是大量的对象。即使使用8个字节的引用，您也可以分配一个268,435,456个对象引用的数组，每个对象引用可以非常大（如果使用嵌套对象，则每个对象引用最多可达2GB）。这比大多数应用程序所需要的更多的内存。

CLR团队的成员之一在这方面发表了博文，并提供了一些解决这些限制的方法。在一个64位的系统上，像BigArray <T>这样的东西是一个可行的解决scheme，可以将任意数量的对象分配到一个数组中 – 远远超过2GB单个对象的限制。 P / Invoke也可以让你分配更大的数组。

编辑：我应该提到这一点，以及 – 我不相信这个行为已经完全改变了.NET 4.自.NET开始以来，行为一直没有改变。

编辑：现在，.NET 4.5将在x64中具有选项，通过在app.config中设置gcAllowVeryLargeObjects来明确允许对象大于2GB。

.NET Framework 4.5允许在64位平台上创build大于2GB的数组。此function默认情况下不启用，必须使用gcAllowVeryLargeObjects元素通过configuration文件启用。

这在数字领域是一个大问题。任何在.NET中使用数字类库的人都将其matrix存储为数组。这样就可以调用本地库来进行数字处理。 2GB限制严重妨碍了64位.NET中可能的matrix大小。更多在这里。