在 CLR 4.0 中，单个对象的大小仍然限制为 2 GB? [英] Single objects still limited to 2 GB in size in CLR 4.0?

问题描述

据我所知，.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 之类的集合使用数组来存储项目，这意味着在 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).

推荐答案

比这更糟糕 - 您是进程空间，当您在 32 位的 .NET 中工作时，它比理论限制要小得多.在 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?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！