Linux中的C ++应用程序的内存稳定性 [英] Memory stability of a C++ application in Linux
问题描述
我想验证我为Linux编写和编译的C ++应用程序的内存稳定性。
这是一个以每秒10-20个连接速率响应远程客户端连接的网络应用程序。
从长远来看，内存上升到50MB，即使应用程序正在调用删除...
I want to verify the memory stability of a C++ application I wrote and compiled for Linux. It is a network application that responds to remote clients connectings in a rate of 10-20 connections per second. On long run, memory was rising to 50MB, eventhough the app was making calls to delete...
调查表明，Linux不会立即释放内存。所以这里是我的问题：
Investigation shows that Linux does not immediately free memory. So here are my questions :
如何强迫Linux释放内存我实际上释放？至少我想这样做一次验证内存的稳定性。
否则，是否有任何可靠的内存指示器，可以报告我的应用程序实际持有的内存？
How can force Linux to free memory I actually freed? At least I want to do this once to verify memory stability. Otherwise, is there any reliable memory indicator that can report memory my app is actually holding?
推荐答案
您看到的内容很可能不是内存泄漏。操作系统和malloc /新堆都是非常复杂的内存记帐。一般来说，这是一件非常好的事情。有机会尝试强制操作系统释放内存只会伤害应用程序性能和整体系统性能。
What you are seeing is most likely not a memory leak at all. Operating systems and malloc/new heaps both do very complex accounting of memory these days. This is, in general, a very good thing. Chances are any attempt on your part to force the OS to free the memory will only hurt both your application performance and overall system performance.
为了说明：
-
Heap保留几个区域的虚拟内存供使用。
The Heap reserves several areas of virtual memory for use. None of it is actually committed (backed by physical memory) until malloc'd.
您分配内存。堆相应地增长。
You allocate memory. The Heap grows accordingly. You see this in task manager.
您在堆上分配更多内存。
You allocate more memory on the Heap. It grows more.
您可以释放在步骤2中分配的内存。但是，堆不能缩减，因为＃3中的内存仍然分配，无法压缩内存（它会使您的指针无效）。
You free memory allocated in Step 2. The Heap cannot shrink, however, because the memory in #3 is still allocated, and Heaps are unable to compact memory (it would invalidate your pointers).
这可能会在步骤＃3中分配的内存之后在之后发生粘连，因为它不能容纳在free #ing的剩余区域，或者因为堆管理器清除堆的效率低下对于由＃2打开的块。 （取决于Heap实现和要分配/释放的内存的块大小）
You malloc/new more stuff. This may get tacked on after memory allocated in step #3, because it cannot fit in the area left open by free'ing #2, or because it would be inefficient for the Heap manager to scour the heap for the block left open by #2. (depends on the Heap implementation and the chunk size of memory being allocated/free'd)
在步骤＃2现在死了世界？不必要。一方面，它可能会被最终重用，一旦这样做效率很高。在不再使用的情况下，操作系统本身可能能够使用CPU的虚拟内存功能（TLB）从应用程序下重新映射未使用的内存，并将其分配给另一个应用程序飞。 Heap知道这一点，并且通常以某种方式管理事物，以帮助提高操作系统重新映射页面的能力。
So is that memory at step #2 now dead to the world? Not necessarily. For one thing, it will probably get reused eventually, once it becomes efficient to do so. In cases where it isn't reused, the Operating System itself may be able to use the CPU's Virtual Memory features (the TLB) to "remap" the unused memory right out from under your application, and assign it to another application -- on the fly. The Heap is aware of this and usually manages things in a way to help improve the OS's ability to remap pages.
这些是有价值的内存管理技术， 如果要检测堆中的小内存泄漏，则需要使用运行时堆泄漏检测工具。既然你提到你也能够在Windows上构建，我会注意到微软的CRT有内置的足够的泄漏检查工具。使用说明：
These are valuable memory management techniques that have the unmitigated side effect of rendering fine-grained memory-leak detection via Process Explorer mostly useless. If you want to detect small memory leaks in the heap, then you'll need to use runtime heap leak-detection tools. Since you mentioned that you're able to build on Windows as well, I will note that Microsoft's CRT has adequate leak-checking tools built-in. Instructions for use found here:
http://msdn.microsoft.com/en-us/library/974tc9t1（v = vs.100）.aspx
也是开源替代malloc可用于GCC / Clang工具链，虽然我没有直接的经验。我认为Linux Valgrind 是泄漏检测的首选和更可靠的方法。 （在我的经验中比MSVCRT Debug更容易使用）。
There are also open-source replacements for malloc available for use with GCC/Clang toolchains, though I have no direct experience with them. I think on Linux Valgrind is the preferred and more reliable method for leak-detection anyway. (and in my experience easier to use than MSVCRT Debug).
这篇关于Linux中的C ++应用程序的内存稳定性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
