C++ 的最大可用内存是多少？ 32位Windows上的应用程序？
只是想知道 C++ 应用程序使用的最大内存是否有限制，
我知道这是 2GB - 这是正确的吗？
如果 C++ 应用程序尝试请求超过 2GB 内存，这是否会导致内存崩溃？
最后一个问题 - 如果运行 C++ 应用程序的计算机内存已经不足，并且 C++ 应用程序需要 100MB 的数组（即连续内存），操作系统是否会使用虚拟内存来适应这一情况？
Just wondering if there is a restriction on the max memory that a C++ application uses
I understand that this is 2GB - Is that correct?
If a C++ app tries to request more then 2GB memory does this cause a memory crash?
Final question - If the machine the C++ app is running on is already low on memory and a C++ app asks for 100MB of array (ie contiguous memory) will the OS accommodate this by using virtual memory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它将导致动态内存分配失败，这通常会导致最终的应用程序崩溃，但从技术上讲，可以编写应用程序来承受此事件。 2GB确实是单个进程的用户地址空间大小——一个应用程序可能使用多个进程（最简单的例子：Chrome）。如果应用程序请求 100MB 的连续内存，则即使物理上不连续，该内存也必须是虚拟连续的，如果没有足够的连续页面可用，则分配失败。
始终使用虚拟内存——所有内存都是虚拟的。
2GB 是大多数情况下的限制。通常情况下，2GB 供用户使用，2GB 供内核使用，但是您可以要求 Windows 为用户提供 3GB，为内核提供 1GB（有一定风险），并且在 64 位上，整个 4GB 的 32 位地址空间可供用户使用。仅当您将应用程序编译为
/LARGEADDRESSAWARE时，增加的地址空间才可用。It will cause a dynamic memory allocation failure, which usually will make the resultant application crash, but technically, an application could be written to withstand this event. 2GB is indeed the user address space size for an individual process- an application may use multiple processes (easiest example: Chrome). If an application asks for 100MB of contiguous memory, that memory must be virtually contiguous even if not physically contiguous, and if there aren't enough contiguous pages available then it's a failed allocation.
Virtual memory is always used- all memory is virtual.
2GB is the limit under most circumstances. What happens is that normally, 2GB is for the user and 2GB for the kernel, but you can ask Windows to make this 3GB for the user and 1GB for the kernel (at some risk), and on 64bit, the whole 4GB of 32bit address space is available to the user. The increased address space is only available if you compile your application as
/LARGEADDRESSAWARE.该限制取决于操作系统。标准 Linux 是 2 Gb，Solaris 是 3 Gb，Windows（据我所知）是 2 或 3，具体取决于 PAE 的使用方式。
但是，您无法获得全部 2G 数据。您的代码将占用其中的一些，您的程序的堆栈将占用一些，C 库将占用一些，您引用的任何其他共享库也将占用一些。通常，操作系统会组织代码、堆和堆栈，以便在它们之间故意留有间隙。
至于你的最后一个问题：都是虚拟内存。您实际上要问的是“如果我机器中的程序使用所有物理内存，操作系统是否会使用交换空间”。答案是肯定的，但并不完全是你想的那样。
CPU只能访问物理RAM。它对磁盘上存储的数据一无所知。因此，为了给正在运行的进程提供物理内存，操作系统将从另一个进程获取该内存。为了获取内存，它会将其写入交换区。当其他进程需要访问内存时，操作系统会将其读回，可能会写入其他进程的内存以进行交换。
The restriction depends on the operating system. Standard Linux is 2 Gb, Solaris is 3 Gb, Windows is (I'm told) 2 or 3 depending on how PAE is used.
However, you don't get all of that 2G for your data. Your code will take some of it, and your program's stack will take some, and the C library will take some, as will any other shared libraries that you reference. Typically the OS will organize the code, heap, and stack such that there are intentional gaps between them.
As for your final question: it's all virtual memory. What you are actually asking is "if the programs in my machine use all that physical memory, will the OS use swap." And the answer is yes, but not quite the way you think.
A CPU can only access physical RAM. It knows nothing of data stored on disk. So to give physical memory to a running process, the OS will take that memory from another process. In order to take the memory, it will write it to swap. When that other process needs to access the memory, the OS will read it back in, potentially writing some other process' memory to swap.
通常，32 位操作系统只能寻址 4GB 物理 RAM。实际上，这个限制往往会较低，但可以通过使用虚拟 RAM 来缓解。在某些版本的 Windows 上，可以通过使用 物理地址扩展。
对于您的问题更重要的是，在 32 位 Windows 上，用户应用程序可用的地址空间也有 2GB 的限制。这对单个应用程序可以使用的内存量施加了严格的限制，无论可用的物理或虚拟 RAM 量有多少。默认 2GB 限制可以增加到 3GB。
以下页面详细说明了这些限制：http:// /msdn.microsoft.com/en-us/library/aa366778(v=vs.85).aspx
Typically, a 32-bit OS can only address 4GB of physical RAM. In practice this limit tends to be somewhat lower, but can be alleviated with the use of virtual RAM. On certain versions of Windows it can be increased through the use of Physical Address Extension.
More importantly to your question, on 32-bit Windows there is also a 2GB limit on the address space available to a user application. This places a hard constraint on the amount of memory that a single application can use, irrespective of the amount of physical or virtual RAM available. The default 2GB limit can be increased to 3GB.
The following page explains the limits in detail: http://msdn.microsoft.com/en-us/library/aa366778(v=vs.85).aspx
尽管其他答案在通常情况下是正确的，但 Windows XP 32 位支持通过使用 地址窗口扩展。
数据库服务器通常使用 AWE 来访问极大的内存集。它需要使用 Win API 来实际管理内存，因此显然只有在真正需要时才使用。
Although the other answers are correct in the usual case, there is support in Windows XP 32 bit to use way more than 3GB of memory by using Address Windowing Extensions.
AWE is commonly used by database servers to enable them to access extremely large sets of memory. It requires using the Win API to actually manage the memory, so it is obviously bes to use only when really needed.
您可以访问的所有内存都是虚拟的 - 您无法直接从应用程序访问物理内存。操作系统将根据需要使用页面文件 - 通过让许多应用程序耗尽物理内存，您将看到的效果是交换增加，并且速度明显减慢。
在 Win 32 位上，应用程序有 2GB 的虚拟地址空间可用。这用于映射可执行文件和 DLL，例如内存映射文件、堆栈和堆。这个空间通常有些分散。如果您的应用程序构建为“大地址感知”，并且操作系统为 64 位或配置为将用户/内核模式内存分割为 3/1GB，则 64 位的地址空间几乎为 4GB，32 位的地址空间为 3GB。少量。
您可以分配的内存通常在 17-1800 MB 范围内。如果您分配小部分，您将达到此目的，如果您尝试分配大的连续块，您可能会更早达到限制，因为您的地址空间是碎片化的。
请参阅 MSDN 上的虚拟地址空间或维基百科上的虚拟地址空间
All the memory you have access to is virtual - you cannot access physical memory directly from an application. The OS will use the page file as needed - the effect you'll see by having many applications exhausting physical memory is increased swapping, and noticable slowdown.
On Win 32 bit, the application has 2GB of Virtual Address Space available. This is used for mapping executables and DLLs, for e.g. memory-mapped files, for stack and heap. This space is typically somewhat fragmented. If your application is built as "Large Address Aware", and the OS is 64-bit or configured to split user/kernel-mode memory as 3/1GB, the address space is almost 4GB for 64-bit, and 3GB for 32-bit.
The memory you can allocate is typically in the 17-1800 MB range. If you allocate small portions, you'll reach this, if you try to allocate large consecutive blocks you may hit the limit a lot earlier, as your address space is fragmented.
See e.g. Virtual Address Space on MSDN or Virtual Address Space on Wikipedia