在32位Windows上,C ++应用程序可用的最大内存是多less?

只是想知道C ++应用程序使用的最大内存是否有限制

我知道这是2GB – 这是正确的吗?

如果一个C ++应用程序试图请求更多的2GB内存,这是否会导致内存崩溃?

最后一个问题 – 如果C ++应用程序运行的机器内存已经很less,并且C ++应用程序要求100MB的数组(即连续内存),操作系统是否可以通过虚拟内存来适应这个问题?

Solutions Collecting From Web of "在32位Windows上,C ++应用程序可用的最大内存是多less?"

这将导致动态内存分配失败,这通常会导致应用程序崩溃,但从技术上讲,可以编写一个应用程序来承受此事件。 2GB确实是单个进程的用户地址空间大小 – 应用程序可能使用多个进程(最简单的示例:Chrome)。 如果应用程序要求100MB的连续内存,那么即使不是物理连续的,该内存也必须是虚拟连续的,并且如果没有足够的连续页面可用,则分配失败。

虚拟内存总是被使用 – 所有的内存都是虚拟的。

2GB是大多数情况下的限制。 通常情况下,2GB是给用户的,2GB是给内核的,但是你可以要求Windows给用户做这个3GB,内核是1GB(有些危险),而在64bit上,整个4GB的32位地址空间可供用户使用。 只有将应用程序编译为/LARGEADDRESSAWARE才能使用增加的地址空间。

限制取决于操作系统。 标准的Linux是2 GB,Solaris是3 GB,Windows是(我被告知)2或3取决于如何使用PAE。

然而,你不能为你的数据得到所有的2G。 你的代码会占用一部分,你的程序的堆栈将会占用一些,C库也会占用一些,就像你引用的其他共享库一样。 通常,操作系统将组织代码,堆和堆栈,以便在它们之间有意向的空白。

至于你最后的问题:这全是虚拟内存。 你真正要问的是“如果我的机器上的程序使用了所有的物理内存,操作系统将使用交换。” 答案是肯定的,但不是你想象的那样。

一个CPU只能访问物理RAM。 它不知道存储在磁盘上的数据。 因此,为了给正在运行的进程提供物理内存,操作系统将从另一个进程获取内存 为了把内存,它将它写入交换。 当其他进程需要访问内存时,操作系统将会读取它,可能会写入其他进程的内存进行交换。

虽然其他答案在通常情况下是正确的,但是在Windows XP 32位中支持通过使用地址窗口化扩展来使用超过3GB内存的方式。

数据库服务器通常使用AWE来访问非常大的内存。 它需要使用Win API来实际管理内存,所以显然只有在真正需要的时候才可以使用。

通常,32位操作系统只能处理4GB的物理RAM 在实践中,这个限制往往会稍微降低,但是可以通过使用虚拟RAM来缓解。 在特定版本的Windows上,可以通过使用物理地址扩展来增加。

更重要的是对于你的问题,在32位Windows上,用户应用程序可用的地址空间也有2GB的限制。 这对单个应用程序可以使用的内存量产生了严格的限制,而与物理或虚拟RAM的数量无关。 默认的2GB限制可以增加到3GB。

以下页面详细解释了限制: http : //msdn.microsoft.com/zh-cn/library/aa366778(v=vs.85).aspx

您有权访问的所有内存都是虚拟的 – 无法直接从应用程序访问物理内存。 操作系统将根据需要使用页面文件 – 通过让很多应用程序耗尽物理内存,您将看到的效果是增加交换,并显着放缓。

在Win 32位上,应用程序有2GB的虚拟地址空间可用。 这用于映射可执行文件和DLL,例如内存映射文件,堆栈和堆。 这个空间通常是有些分散的。 如果您的应用程序构建为“大型地址识别”,并且操作系统为64位或配置为将用户/内核模式内存拆分为3 / 1GB,则64位的地址空间几乎为4GB,32位的地址空间为3GB,位。

您可以分配的内存通常在17-1800 MB的范围内。 如果你分配一小部分,你会达到这个,如果你尝试分配大的连续块,你可能会提前很多,因为你的地址空间是分散的。

请参阅MSDN上的 虚拟地址空间或维基百科上的虚拟地址空间

2GB的限制仅限于1个进程。 您可以通过N个进程(32位)分配您的应用程序来分配N x 2GB。 操作系统必须仍然是64位。 你必须处理过程之间的沟通。