C++一旦内存使用量达到 1.5 GB，应用程序就会崩溃
我们有一个在 Windows 32 位系统上运行的 C++ 应用程序。一旦内存使用量达到 1.5 GB，就会崩溃。我们无法理解的是为什么它在 1.5 GB 限制而不是 2 GB 限制（虚拟地址空间和 Windows 32 位架构限制）时崩溃？
其他细节：- 可用总内存：4GB
操作系统：Windows XP
1.5 GB 是这一进程所使用的内存。
问候，
萨钦
We have a C++ application running on Windows 32 bit system. It crashes once the memory usage reaches 1.5 GB. What we are unable to understand is why it's crashing at 1.5 GB limit and not at 2 GB limit (the virtual address space and windows 32 bit architecture limit)?
Other details:-
Total memory available : 4GB
Operating System : Windows XP
1.5 GB is the memory used by just this one process.
Regards,
Sachin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这在 32 位 Windows 下是完全正常的。
除非您激活了 /3gb 开关，否则您的总地址空间为 2GB。然而，这减去映射的可执行文件和至少六个 DLL 和 NLS 文件（对于“hello world”——真正的应用程序可能有十几个或两打）。
由于它们的放置位置不理想，因此您会损失大约半 GB 的地址空间。堆不会增长到“进入”该区域，因此分配超过 1.5GB 的空间将会失败。
“典型程序”的地址空间如下所示：
请注意，一个 DLL 是多么巧妙放置在大约 1/3 的地址空间，有效地“切断”了您可以使用的三分之一的内存。
This is perfectly normal under 32bit Windows.
Unless you have the /3gb switch activated, you have a total address space of 2GB. However, that's minus the mapped executable and at least half a dozen DLL and NLS files (for "hello world" -- a real application would probably have more like a dozen or two dozen of them).
Since they are not optimally placed, you lose about half a gigabyte of addres space. The heap will not grow "into" that region, and thus allocating more than 1.5GB will fail.
Here is what the address space of a "typical program" looks like:
Note how very skillfully one DLL is placed at about 1/3 of the address space, effectively "cutting off" a third of the memory that you can use.
虚拟内存碎片可能是一个原因。
另一个可能的原因是内存管理器（内存池）通常是如何工作的。内存管理器尝试保留比前一个内存块多 2 倍的内存块。当内存分配已经相当多时，这个数量将非常大，并且内存分配将会失败，尽管实际上仍然有可用内存。
The fragmentation of the virtual memory could be a reason.
One more possible reason is how memory managers (memory pools) are usually work. Memory manager attempts to reserve a block of memory 2 times more than the previous one. When memory is allocated already quite a lot, this amount will be very large and a memory allocation will fail despite the fact that in reality there is still available memory.
您可以启用博士。 watson 作为默认调试器，看看是否可以捕获崩溃转储，然后使用 Visual Studio 或 Windbg 打开转储，您可以看到崩溃之前的调用堆栈，然后知道崩溃的真正原因是什么。
You can enable dr. watson as default debugger and see if a crash dump could be catched, then open the dump with visual studio or windbg and you can see the callstack before crash, and then know what is the real cause of the crash.