哪个是.NET托管代码中可以实现的最大内存量?它取决于实际架构(32/64位)吗?
.NET代码没有严格的确切数字.
如果你在32位Windows上运行; 如果在Windows Server 2003上使用/ 3GB开关,您的进程最多可以处理2 GB,3 GB.
如果在64位盒上运行64位进程,如果存在大量RAM,则进程可以处理最多8 TB的地址空间.
然而,这不是全部故事,因为CLR为每个进程花费了一些开销.与此同时,.NET将尝试以块的形式分配新的内存; 如果地址空间碎片化,这可能意味着您无法分配更多内存,即使有些内存可用.
在C#2.0和3.0中,托管代码中单个对象的大小也有2G限制.
.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
对于64位Windows,虚拟内存大小为16 TB,在用户和内核模式之间平均分配,因此用户进程可以处理8 TB(8192 GB).这比64位可寻址的整个16 EB空间要少,但它仍然比我们习惯的32位更多.
我最近在32位进程上对.NET中的内存限制进行了大量的分析.我们都被我们在.NET应用程序中分配高达2.4GB(2 ^ 31)的想法所震撼,但不幸的是,这不是真的:(.应用程序进程有很大的空间可供使用,操作系统也很棒但是,.NET本身似乎有自己的开销,对于推动内存限制的典型实际应用程序来说,它本身就有大约600-800MB的占用空间.这意味着只要你分配一个整数数组就可以了1.4GB,你应该期望看到一个OutOfMemoryException().
显然在64位,这个限制发生的方式稍晚(让我们在5年内聊聊:)),但由于字数增加,内存中所有内容的一般大小也会增长(我发现它是~1.7到2倍).
我所知道的是,操作系统中的虚拟内存理念绝对不能在一个进程中为您提供几乎无限的分配空间.只有这样才能使完整的2.4GB可以同时运行所有(许多)应用程序.
我希望这种见解有所帮助.
我最初在这里回答了一些相关内容(我还是一个新手,所以我不确定我应该怎么做这些链接):
单个.NET进程是否有内存限制