内存使用和最小化
我们有一个相当图形密集型的应用程序，它使用 FOX 工具包和 OpenSceneGraph，当然还有 C++。我注意到，运行应用程序一段时间后，似乎存在内存泄漏。然而，当我最小化时，大量内存似乎被释放（如 Windows 任务管理器中所见）。当应用程序恢复时，内存使用量会上升，但会稳定在低于最小化之前的水平。
这是一个巨大的迹象表明我们存在严重的内存泄漏吗？或者这可能与 Windows 处理图形应用程序的方式有关？我不太确定发生了什么事。
We have a fairly graphical intensive application that uses the FOX toolkit and OpenSceneGraph, and of course C++. I notice that after running the application for some time, it seems there is a memory leak. However when I minimize, a substantial amount of memory appears to be freed (as witnessed in the Windows Task Manager). When the application is restored, the memory usage climbs but plateaus to an amount less than what it was before the minimize.
Is this a huge indicator that we have a nasty memory leak? Or might this be something with how Windows handles graphical applications? I'm not really sure what is going on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您正在查看程序的工作集大小。 RAM 中实际存在的程序虚拟内存页的总和。当您最小化主窗口时，Windows 会假设用户暂时不会对该程序感兴趣，并会积极修剪工作集。将 RAM 中的页面复制到页面文件并将其丢弃，为用户可能启动或切换到的其他进程腾出空间。
当用户启动另一个需要大量 RAM 的程序时，这个数字也会自动下降。 Windows 会丢弃您的页面以为该程序腾出空间。它会选择您的程序一段时间未使用的页面，这可能不会对您的程序的性能产生太大影响。
当您切换回程序时，Windows 需要将页面交换回 RAM。但这是按需的，它只分页到您的程序实际使用的页面。这通常会比以前使用的要少，例如不需要将程序的初始化代码交换回来。
不用说，这个数字与程序的内存使用量完全无关，它只是一个统计数字。
私有字节可以更好地指示内存泄漏。 Taskmgr 没有显示这一点，SysInternals 的 ProcMon 工具可以显示这一点。它仍然不是一个很好的指标，因为该数字还包括堆中由程序释放并添加到空闲块列表中以供重新使用的任何块。没有好的方法来测量实际使用的内存，请阅读 HeapWalk() API 函数的小字以了解造成的麻烦。
Windows 中的内存和堆管理器过于复杂，无法从可用的数字中得出结论。使用泄漏检测工具，例如 VC 调试分配器 (crtdbg.h)。
You are looking at the working set size of your program. The sum of the virtual memory pages of your program that are actually in RAM. When you minimize your main window, Windows assumes the user won't be interested in the program for a while and aggressively trims the working set. Copying the pages in RAM to the paging file and chucking them out, making room for the other process that the user is likely to start or to switch to.
This number will also go down automatically when the user starts another program that needs a lot of RAM. Windows chucks out your pages to make room for this program. It picks pages that your program hasn't used for a while, making it likely that this doesn't affect the perf of your program much.
When you switch back to your program, Windows needs to swap pages back into RAM. But this is on-demand, it only pages-in pages that your program actually uses. Which will normally be less than what it used before, no need to swap the initialization code of your program back in for example.
Needless to say perhaps, the number has absolutely nothing to do with the memory usage of your program, it is merely a statistical number.
Private bytes would be a better indicator for a memory leak. Taskmgr doesn't show that, SysInternals' ProcMon tool does. It still isn't a great indicator because that number also includes any blocks in the heap that were freed by your program and were added to the list of free blocks, ready to be re-used. There is no good way to measure actual memory in use, read the small print for the HeapWalk() API function for the kind of trouble that causes.
The memory and heap manager in Windows are far too sophisticated to draw conclusions from the available numbers. Use a leak detection tool, like the VC debug allocator (crtdbg.h).
您所看到的只是内存缓存。当您调用 free()/delete()/delete 时，大多数实现实际上不会将此内存返回给操作系统。他们会保留它，以便在您下次请求时以更快的速度归还。当您的应用程序最小化时，他们将释放此内存，因为您不会很快请求它。
您不太可能发生实际的内存泄漏。任务管理器不是特别准确，并且有很多行为可以改变您正在使用的内存量 - 即使您正确释放了内存。如果您仍然担心，您需要获得一个实际的内存分析器来查看。
另外，是的，Windows 在最小化应用程序时做了很多事情。例如，如果您使用 Direct3D，则会发生设备丢失。有线程计时的东西。 Windows 旨在为用户一次在单个应用程序中提供最佳体验，并且很可能会从应用程序中占用额外的缓存/缓冲资源来实现此目的。
What you are seeing is simply memory caching. When you call free()/delete()/delete, most implementations won't actually return this memory to the OS. They will keep it to be returned in a much faster fashion the next time you request it. When your application is minimized, they will free this memory because you won't be requesting it anytime soon.
It's unlikely that you have an actual memory leak. Task Manager is not particularly accurate, and there's a lot of behaviour that can change the apparent amount of memory that you're using- even if you released it properly. You need to get an actual memory profiler to take a look if you're still concerned.
Also, yes, Windows does a lot of things when minimizing applications. For example, if you use Direct3D, there's a device loss. There's thread timings somethings. Windows is designed to give the user the best experience in a single application at a time and may well take extra cached/buffered resources from your application to do it.
不，您看到的效果意味着您的平台在不可见时释放资源（好事），这似乎清除了一些缓存的数据，这些数据在恢复窗口后不会恢复。
这样做可能会帮助您发现内存泄漏。如果应用程序使用的最小内存量（虽然最小化）随着时间的推移而增长，则表明存在泄漏。
No, there effect you are seeing means that your platform releases resources when it's not visible (good thing), and that seems to clear some cached data, which is not restored after restoring the window.
Doing this may help you find memory leaks. If the minimum amount of memory (while minimized) used by the app grows over time, that would suggest a leak.