最大.NET可实现的内存?

时间:2009-04-04 09:01:37

标签: .net memory

.NET托管代码中可以实现的最大内存量是多少?它取决于实际架构(32/64位)吗?

9 个答案:

答案 0 :(得分:11)

.NET代码没有严格的确切数字。

如果你在32位Windows上运行;如果在Windows Server 2003上使用/ 3GB开关,则进程最多可以处理2 GB,3 GB。

如果在64位盒子上运行64位进程,那么进程可以解决最多8 TB的地址空间,如果存在那么多的RAM。

然而,这不是全部,因为CLR会为每个进程带来一些开销。与此同时,.NET将尝试以块的形式分配新的内存;如果地址空间是碎片的,这可能意味着你不能分配更多的内存,即使有些内存可用。

答案 1 :(得分:7)

在C#2.0和3.0中,托管代码中单个对象的大小也有2G限制。

答案 2 :(得分:7)

.NET进程可以处理的内存量取决于它是否在32/64位计算机上运行,​​以及它是否作为CPU不可知或CPU特定进程运行。

默认情况下,.NET进程与CPU无关,因此它将使用Windows版本自然的进程类型运行。在64位中它将是64位进程,在32位中它将是32位进程。您可以强制.NET进程来定位特定的CPU,并说它在64位计算机上作为32位进程运行。

如果排除大地址识别设置,则以下是各种故障

  • 32位进程可以解决2GB
  • 64位进程可以解决8TB

以下是基于Windows提供的各种选项的可寻址空间完整细分的链接。

http://msdn.microsoft.com/en-us/library/aa366778.aspx

答案 3 :(得分:5)

对于64位Windows,虚拟内存大小为16 TB,在用户和内核模式之间平均分配,因此用户进程可以处理8 TB(8192 GB)。这比64位可寻址的整个16 EB空间要小,但它仍然比我们习惯的32位更多。

答案 4 :(得分:5)

我最近在32位进程中对.NET中的内存限制进行了大量的分析。我们都被我们在.NET应用程序中分配高达2.4GB(2 ^ 31)的想法所震撼,但不幸的是,这不是真的:(。应用程序进程有很大的空间可供使用,操作系统也很棒但是,.NET本身似乎有自己的开销,对于推动内存限制的典型实际应用程序来说,它本身就有大约600-800MB的占用空间。这意味着只要你分配一个整数数组就可以了1.4GB,你应该会看到一个OutOfMemoryException()。

显然在64位,这个限制发生的方式稍晚(让我们在5年内聊聊:)),但是内存中所有内容的一般大小也会增长(我发现它的大小是~1.7到2倍),因为字大小增加了

我确切知道,操作系统中的虚拟内存理念肯定不会在一个进程中为您提供几乎无限的分配空间。只有这样才能使完整的2.4GB可以同时运行所有(许多)应用程序。

我希望这种见解有所帮助。

我最初在这里回答了一些相关内容(我还是一个新手,所以我不确定我应该怎么做这些链接):

Is there a memory limit for a single .NET process

答案 5 :(得分:3)

.NET运行时可以为其主机中的用户模式程序分配所有可用内存。请注意,这并不意味着所有内存都将专用于您的程序,因为一些(相对较小的)部分将专用于内部CLR数据结构。 在32位系统中,假设设置为4GB或更多(即使启用了PAE),您应该能够获得分配给您的应用程序的最大2GB。在64位系统上,您应该能够获得1TB。有关Windows内存限制的详细信息,请查看this page。 每个提到的数字必须除以2,因为windows保留了较高的一半地址空间供在内核模式下运行的代码(环0)使用。 此外,请注意,对于32位系统,限制超过4GB时,隐含使用PAE,因此除非操作系统支持4gt,否则您仍然不能超过2GB限制,在这种情况下您可以达到高达3GB。

答案 6 :(得分:2)

是的,在32位环境中,您只能使用4GB的地址空间,但Windows声称只有一半。在64位架构上,它确实更大。我相信它是4G * 4G

在Compact Framework上,它通常是几百MB的顺序

答案 7 :(得分:0)

我认为其他答案非常幼稚,在2GB内存消耗后的现实世界中,您的应用程序将表现得非常糟糕。根据我的经验,在大量内存消耗之后,GUI通常变得非常笨重,无法使用。

这是我的经验,显然,实际原因可能是对象变得太大,因此对这些对象的所有操作都需要花费太多时间。

答案 8 :(得分:0)

以下博客文章详细介绍了x86和x64 max memory。它还有一个小工具(可用源),可以轻松地将不同的内存选项放在一起: http://www.guylangston.net/blog/Article/MaxMemory