Linux 上的虚拟内存会用完吗？
我的应用程序类似于假设的程序：
for(;;) {
for (i=0; i<1000; i++) {
p[i] = malloc(random_number_between_1000_and_100000());
p[i][0]=0; // update
}
for (i=0; i<1000; i++) {
free(p[i]);
}
}
没有内存泄漏，但在我的系统上，内存消耗（顶部、列 VSS）无限增长（例如达到可用物理内存的 300%）。这是正常的吗？
更新 - 使用内存一段时间然后释放它。这有区别吗？
My application similar to hypotetical program:
for(;;) {
for (i=0; i<1000; i++) {
p[i] = malloc(random_number_between_1000_and_100000());
p[i][0]=0; // update
}
for (i=0; i<1000; i++) {
free(p[i]);
}
}
Has no memory leaks but on my system, the consumption of memory (top, column VSS) grows without limits (such as to 300% of available physical memory). Is this normal?
Updated - use the memory for a while and then free it. Is this a difference?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
该行为是正常的。引用
man 3 malloc：BUGS
默认情况下，Linux 遵循乐观的内存分配策略。这意味着当 malloc() 返回非 NULL 时，不能保证
内存确实可用。这是一个非常糟糕的错误。万一发现系统内存不足，一个或多个进程将被
被臭名昭著的 OOM 杀手杀死。如果在不希望突然随机丢失一些信息的情况下使用 Linux
选择的进程，而且内核版本足够新，可以使用以下命令关闭这种过度使用行为：
另请参阅内核文档目录、文件 vm/overcommit-accounting 和 sysctl/vm.txt。
您需要触摸（读/写）Linux 内核的内存才能实际保留它。
The behavior is normal. Quoting
man 3 malloc:BUGS
By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the
memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be
killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly
picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like:
See also the kernel Documentation directory, files vm/overcommit-accounting and sysctl/vm.txt.
You need to touch (read/write) the memory for the Linux kernel to actually reserve it.
尝试
在每个循环的末尾添加，看看是否有区别。
free() 仅释放内存，但不会将其返还给操作系统。
Try to add
at end of each loop to see if it makes difference.
The free() only deallocates memory but it doesn't give it back to OS.
操作系统通常将所有页面分配为“0”的写入时复制克隆
页，即用零填充的固定页。从页面中读取
将按预期返回 0。只要您阅读，所有参考文献都会消失
相同的物理内存。一旦你写了一个值，“COW”就是
已损坏，并为您分配了一个真实的物理页框。这
意味着只要不写入内存就可以保留
分配内存直到虚拟内存地址空间用完或
您的页表填满了所有可用内存。
The OS usually allocates all pages as Copy-On-Write clones of the "0"
page, that is a fixed page filled with zeros. Reading from the pages
will return 0 as expected. As long as you only read, all references go
the same physical memory. Once you write a value the "COW" is
broken and a real, physical, page frame is allocated for you. This
means that as long as you don't write to the memory you can keep
allocating memory until the virtual memory address space runs out or
your page table fills up all available memory.
只要您不触及那些分配的块，系统就不会真正为您分配它们。
但是，您可能会耗尽可寻址空间，这是操作系统对进程施加的限制，并且不一定是您可以使用系统指针类型寻址的最大空间。
As long as you don't touch those allocated chunks the system will not really allocate them for you.
However you can run out of addressable space which is a limit the OS imposes to the processes, and is not necessarily the maximum you can address with the systems pointer type.