只是想知道C ++应用程序使用的最大内存是否有限制
我知道这是2GB – 这是正确的吗？
如果一个C ++应用程序试图请求更多的2GB内存，这是否会导致内存崩溃？
最后一个问题 – 如果C ++应用程序运行的机器内存已经很less，并且C ++应用程序要求100MB的数组（即连续内存），操作系统是否可以通过虚拟内存来适应这个问题？
这将导致动态内存分配失败，这通常会导致应用程序崩溃，但从技术上讲，可以编写一个应用程序来承受此事件。 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位。 你必须处理过程之间的沟通。