据我了解，.NET中的单个实例有2 GB的限制。到目前为止，由于我主要从事32位OS的开发，因此我并未对此进行过多关注。在32上，但无论如何还是一个人为的限制。但是，得知此限制也适用于64位.NET时，我感到非常惊讶。

由于List<T>之类的集合使用数组来存储项目，这意味着在32位上运行的.NET应用程序与在64位上运行的同一应用程序相比，列表中的引用类型项的容纳量将是其两倍。 imo真是令人惊讶。

有人知道这种限制是否在CLR 4.0中得到解决（目前我手头没有安装4.0）。

评论

2012年更新：从.NET 4.5开始，在x64系统上，开发人员现在可以分配大于2GB（更大）的对象。 2GB的限制已用完。 centerspace.net/blog/nmath/large-matrices-and-vectors/…
正确的链接似乎是centerspace.net/blog/nmath/large-matrices-and-vectors
即使更正的链接也已死:(
请尝试使用此链接以获取有关绕过2GB限制（MSDN）的信息msdn.microsoft.com/zh-cn/library/hh285054(v=vs.110).aspx
更正的链接：centerspace.net/large-matrices-and-vectors

#1 楼

比这更糟的是-您正在处理空间，当您在32位.NET中工作时，它比理论上的限制小得多。在32位.NET应用程序中，我的经验是，您总是会趋向于开始摆脱大约1.2-1.4gb内存使用量的内存错误（有些人说可以达到1.6 ...但是我从未见过） ）。当然，在64位系统上这不是问题。也就是说，即使在64位系统上，单个2GB的引用类型数组也是大量对象。即使使用8个字节的引用，您也可以分配268,435,456个对象引用的数组-每个对象引用都可以非常大（最大2GB，如果使用嵌套对象，则更多）。这比大多数应用程序实际所需的内存更多。

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


编辑：我也应该提到这一点-我不相信这种行为对于.NET 4完全没有改变。 .NET的行为自.NET开始以来一直没有改变。.NET4.5现在将在x64中具有通过在其中设置gcAllowVeryLargeObjects显式允许对象大于2gb的选项。 app.config。

评论

我知道对32位的所有限制，但这并不是我提出问题的重点。令人惊讶的是，实际上在64位上情况更糟。我将看一下博客文章。感谢您的链接。

–布莱恩·拉斯穆森（Brian Rasmussen）
09年7月6日在16:56
没问题-我刚刚补充说，因为64位确实比32位还差。理论上的限制是对象的1/2，但是由于您实际上仅限于总共1.4gb的处理空间，因此无法使对象引用数组甚至接近允许大小的一半。 （每个引用都要求它指向某个内容以及引用的大小...。因此，在大多数情况下，您实际上最多限制了.NET 32bit中约1 / 4gb的引用）。

– Reed Copsey
09年7月6日在17:02
布莱恩：这只是64位与32位相比的另一个缺点（尽管是IMO）。有许多理由不转向64位-但是人们似乎忘记了这一点，认为64位会自动变得更好。

– Reed Copsey
09年7月6日在17:07
我读过Mono在C＃中支持64位数组（例如，具有2 ^ 32个以上条目的数组）

– Alex Black
09年7月6日在18:41
是的，Mono做到了。注意，所有CLR实现都具有理论能力（所有数组都具有long LongLength属性），但到目前为止，只有Mono实际使用了它。

– Pavel Minaev
09-9-24 at 16:39

#2 楼

.NET Framework 4.5允许在64位平台上创建大于2GB的阵列。默认情况下，此功能未启用，必须使用gcAllowVeryLargeObjects元素通过配置文件启用它。
.110）.aspx

评论

我没注意到。感谢您的链接。

–布莱恩·拉斯穆森（Brian Rasmussen）
2012年3月9日20:46
还是只有4GB ！？他们为什么不能做真正的64位？

–里克·梅里奇（Rick Minerich）
2012年5月24日下午4:22
@MarcGravell“数组中元素的最大数量为UInt32.MaxValue。”

–里克·梅里奇（Rick Minerich）
2012年7月10日19:11
@里克k;那么带有uint.MaxValue元素的int []有多大？

– Marc Gravell♦
2012年7月10日在19:13
因此，如果您需要一个字节[]，则限于4GB。

– Binki
16年8月13日在13:59

#3 楼

在数值领域这是一件大事。在.NET中使用数字类库的任何人都将其矩阵存储为下面的数组。这样就可以调用本机库来进行数字运算。 2GB的限制严重阻碍了64位.NET中可能的矩阵大小。更多内容。

评论

我们已经与Microsoft讨论了此问题。它不太可能在.NET 4.0中修复，但他们似乎很乐于找到解决方案。我认为我们最终将使用长索引数组，但更有可能是某种巨型blob对象。

–特雷弗·米斯费尔特（Trevor Misfeldt）
09年10月8日在2:51
65536 * 65536浮点数组的性能与65536浮点数组的65536数组的性能相比如何？ 256个浮点数的256个数组的性能将不如256 * 256数组，因为后者将具有更好的缓存局部性，而前者则不会，但是如果访问的是矩阵中足够本地化的行以受益从缓存位置来看，我认为一个处理器将能够缓存对象表引用。

–超级猫
2011-3-24的3:39