new[] 在填充之前不会减少可用内存
这是在 CentOS 64 位上使用 G++ 4.1.2 的 C++ 语言。
我们正在编写一个测试应用程序，以将系统上的内存使用量增加 n GB。这个想法是通过 SNMP 等来监控整个系统负载。所以这只是一种监控方式。
然而，我们所看到的是，简单地执行：
char* p = new char[1000000000];
不会影响使用的内存，如 top 或 free -m 中所示
内存分配似乎只有在内存被写入后才变得“真实”：
memcpy(p, 'a', 1000000000); //shows an increase in mem usage of 1GB
但我们必须写入所有内存，仅写入第一个元素并不会显示已用内存的增加：
p[0] = 'a'; //does not show an increase of 1GB.
这正常吗，内存实际上已完全分配吗？我不确定是否是我们使用的工具（top 和 free -m）显示了不正确的值，或者编译器或运行时和/或内核中是否发生了一些巧妙的事情。
即使在关闭优化的调试版本中也会出现这种行为。
据我了解， new[] 立即分配内存。 C++ 运行时是否会延迟此实际分配，直到稍后访问它。在这种情况下，内存不足异常是否可以推迟到实际分配内存之后，直到访问内存为止？
事实上，这对我们来说不是问题，但很高兴知道为什么会这样！
干杯!
编辑：
我不想知道我们应该如何使用向量，这不是 OO / C++ / 当前的做事方式等等。我只想知道为什么会这样，而不是对尝试其他方法有建议。
This is in C++ on CentOS 64bit using G++ 4.1.2.
We're writing a test application to load up the memory usage on a system by n Gigabytes. The idea being that the overall system load gets monitored through SNMP etc. So this is just a way of exercising the monitoring.
What we've seen however is that simply doing:
char* p = new char[1000000000];
doesn't affect the memory used as shown in either top or free -m
The memory allocation only seems to become "real" once the memory is written to:
memcpy(p, 'a', 1000000000); //shows an increase in mem usage of 1GB
But we have to write to all of the memory, simply writing to the first element does not show an increase in the used memory:
p[0] = 'a'; //does not show an increase of 1GB.
Is this normal, has the memory actually been allocated fully? I'm not sure if it's the tools we are using (top and free -m) that are displaying incorrect values or whether there is something clever going on in the compiler or in the runtime and/or kernel.
This behavior is seen even in a debug build with optimizations turned off.
It was my understanding that a new[] allocated the memory immediately. Does the C++ runtime delay this actual allocation until later on when it is accessed. In that case can an out of memory exception be deferred until well after the actual allocation of the memory until the memory is accessed?
As it is it is not a problem for us, but it would be nice to know why this is occurring the way it is!
Cheers!
Edit:
I don't want to know about how we should be using Vectors, this isn't OO / C++ / the current way of doing things etc etc. I just want to know why this is happening the way it is, rather than have suggestions for alternative ways of trying it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您的库从操作系统分配内存时，操作系统只会在进程的虚拟地址空间中保留一个地址范围。操作系统没有理由实际提供此内存，除非您使用它 - 正如您所演示的那样。
如果您查看例如
/proc/self/maps，您将看到地址范围。如果您查看 top 的内存 use，您将看不到它 - 您还没有使用它。When your library allocates memory from the OS, the OS will just reserve an address range in the process's virtual address space. There's no reason for the OS to actually provide this memory until you use it - as you demonstrated.
If you look at e.g.
/proc/self/mapsyou'll see the address range. If you look at top's memory use you won't see it - you're not using it yet.请查找过度使用的情况。默认情况下，Linux 在访问内存之前不会保留内存。如果您最终需要的内存多于可用内存，您不会收到错误，但随机进程会被终止。您可以使用
/proc/sys/vm/*控制此行为。IMO，过度使用应该是每个进程的设置，而不是全局的设置。默认情况下不应过度使用。
Please look up for overcommit. Linux by default doesn't reserve memory until it is accessed. And if you end up by needing more memory than available, you don't get an error but a random process is killed. You can control this behavior with
/proc/sys/vm/*.IMO, overcommit should be a per process setting, not a global one. And the default should be no overcommit.
关于问题的后半部分：
语言标准不允许在抛出 bad_alloc 时出现任何延迟。这必须作为 new[] 返回指针的替代方案发生。以后不可能发生这种事！
某些操作系统可能会尝试过度使用内存分配，但随后会失败。这不符合C++语言标准。
About the second half of your question:
The language standard doesn't allow any delays in throwing a bad_alloc. That must happen as an alternative to new[] returning a pointer. It cannot happen later!
Some OSs might try to overcommit memory allocations, and fail later. That is not conforming to the C++ language standard.