问题描述

据我了解，.NET 中的单个实例有 2 GB 的限制.因为到目前为止我主要在 32 位操作系统上工作，所以我没有对此给予太多关注.在 32 上，但这或多或少是人为的限制.但是，当我得知 此限制也适用于64 位 .NET.

As I understand it there's a 2 GB limit on single instances in .NET. I haven't paid a lot of attention to that since I have mainly worked on 32 bit OS so far. On 32 but it is more or less an artificial limitation anyway. However, I was quite surprised to learn that this limitation also applies on 64 bit .NET.

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

Since collections such as List<T> use an array to store items, that means that a .NET application running on 32 bit will be able to hold twice as many reference type items in a list compared to the same application running on 64 bit. That is quite surprising imo.

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

Does anyone know if this limitation is addressed in CLR 4.0 (I don't have a 4.0 installation at hand at the moment).

推荐答案

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

It's worse than that - you're process space, when you're working in .NET in 32bit is much smaller than the theoretical limit. In 32bit .NET apps, my experience is that you'll always tend to start getting out of memory errors somewhere around 1.2-1.4gb of memory usage (some people say they can get to 1.6... but I've never seen that). Of course, this isn't a problem on 64bit systems.

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

That being said, a single 2GB array of reference types, even on 64bit systems, is a huge amount of objects. Even with 8 byte references, you have the ability to allocate an array of 268,435,456 object references - each of which can be very large (up to 2GB, more if they're using nested objects). That's more memory than would ever really be required by most applications.

CLR 团队的一位成员在博客上写了这篇文章，提供一些解决这些限制的方法的选项.在 64 位系统上，做类似他的 BigArray<T>将任意数量的对象分配到一个数组中是一个可行的解决方案——远远超过 2gb 的单个对象限制.P/Invoke 也可以让你分配更大的数组.

One of the members of the CLR team blogged about this, with some options for ways to work around these limitations. On a 64bit system, doing something like his BigArray<T> would be a viable solution to allocate any number of objects into an array - much more than the 2gb single object limit. P/Invoke can allow you to allocate larger arrays as well.

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

I should have mentioned this, as well - I do not believe this behavior has changed at all for .NET 4. The behavior has been unchanged since the beginning of .NET.

.NET 4.5 现在可以在 x64 中选择通过设置 gcAllowVeryLargeObjects 在 app.config 中.

.NET 4.5 will now have the option in x64 to explicitly allow objects to be larger than 2gb by setting gcAllowVeryLargeObjects in the app.config.

这篇关于在 CLR 4.0 中，单个对象的大小仍限制为 2 GB?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！