.NET托管代码能够达到的最大内存量是多少?它是否取决于实际架构(32/64位)?
.NET托管代码能够达到的最大内存量是多少?它是否取决于实际架构(32/64位)?
.NET代码没有确定的硬性数字。
如果您在32位Windows上运行,则您的进程可以寻址多达2 GB的空间,在Windows Server 2003上使用/3GB开关则可以寻址3 GB。
如果您在64位框架上运行64位进程,则进程可以寻址高达8 TB的地址空间,如果有那么多RAM可用。
然而,这并不是整个故事,因为CLR每个进程都需要一些开销。同时,.NET会尝试以块的方式分配新的内存;如果地址空间被分段,那可能意味着即使有一些内存可用,也无法分配更多内存。
显然,在64位上,这个限制发生得晚得多(让我们在5年后再聊:)),但由于字长增加,内存中所有东西的总体大小也会增长(我发现它大约是1.7到2倍)。
我确定的是,操作系统中的虚拟内存概念绝对不能为一个进程提供几乎无限的分配空间。它只存在于此,以便所有(许多)正在运行的应用程序都可以寻址完整的2.4GB。
希望这些见解能在某种程度上有所帮助。
我最初在这里回答了相关问题(我仍然是新手,所以不确定我应该如何处理这些链接):
是的,在32位环境下,您的地址空间受限于4GB,但Windows占用了一半左右。在64位架构中,它要大得多。我相信它是4G * 4G。
而在紧凑框架上,通常是几百MB的数量级。
我认为其他答案都相当幼稚,在现实世界中,当内存消耗达到2GB后,您的应用程序将表现得非常糟糕。根据我的经验,GUI在大量内存消耗后通常会变得非常笨重,难以使用。
这是我的经验,显然,造成这种情况的实际原因可能是对象增长过大,因此对这些对象的所有操作都需要太多时间。