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文件启用。

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

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