所以，我最近注意到，在某个项目完成开发之后，我们的开发服务器在4GB内存中稳定了~300MB。假设这是由于开发阶段内存泄漏造成的，那么该内存最终会自行释放还是需要重启服务器。是否有任何工具可用于在未来防止这种情况（除了明显的“不写代码产生内存泄漏”）？有时他们看不见了一段时间，随着时间的推移，我猜他们会在你继续测试你的应用程序时加起来。
答案 0 :(得分：2)
您在运行什么操作系统？如今，大多数操作系统都会在进程退出时清理泄漏的内存。您正在使用的内存可能实际上用于文件系统缓存。这无需担心 - 如有必要，操作系统将回收此内存。
来自：http://learnlinux.tsf.org.za/courses/build/internals/ch05.html
指示的可用内存量 free命令包括当前 缓冲区缓存的大小 计算。这是误导性的 指示的可用内存量 通常会很低，作为缓冲区 缓存很快就会填满大部分用户内存。 不要'恐慌。应用程序是 可能不会占用你的内存;它是 只是正在采取的缓冲区缓存 所有可用空间。缓冲区 缓存计为可用的内存空间 用于应用程序（记住它 它将根据需要缩小），所以 减去缓冲区缓存的大小 看到真正的可用内存量 可供应用程序使用
答案 1 :(得分：1)
使用Linux x86盒子上的例外valgrind运行程序。
Windows上提供了一个商业等效的Purify。
程序的这些运行时分析将报告内存泄漏和其他错误，如缓冲区溢出和单元化变量。
静态代码分析 - 例如Lint和Coverity - 还可以发现内存泄漏和更严重的错误。
让我们具体说明内存泄漏的原因以及它们如何损害您的程序：
如果在程序运行期间“泄漏”内存，则应用程序最终会耗尽RAM和交换，或程序可用的地址空间（可能小于物理RAM）并导致下一个分配失败。绝大多数程序都无法捕获此错误，因为错误检查比看起来更难。大多数程序要么通过取消引用空指针而失败，要么退出。
答案 2 :(得分：1)
最好在开发过程中对抗它们，因为这样可以更容易地识别引入泄漏的修订版。正如你现在可能看到的那样，事后非常非常努力地做到这一点。在运行我推荐的工具时会出现很多报告：
http://www.ibm.com/software/awdtools/purify/
http://directory.fsf.org/project/ElectricFence/
我建议你运行这些工具，禁止大多数有关泄漏的警告，然后逐一修复它们，删除抑制。
然后，确保定期运行这些工具并快速修复任何回归！
答案 3 :(得分：1)
当然，显而易见的答案是“不要编写产生内存泄漏的代码”并且它是有效的，因为如果你有引用计数问题，或者很难跟踪的复杂代码，它们可能非常难以修复记忆的一生。
为了解决您目前的情况，您可以考虑使用DevPartner for Windows或Valgrind for Linux / Unix等工具，我发现这两种工具对于追踪内存泄漏（以及其他问题等）非常有效。作为性能瓶颈）。
您可能希望考虑的另一件事是查看您对指针的使用，如果可以的话，用智能指针慢慢替换它们，这应该有助于管理指针的生命周期。
不，我怀疑在没有重新启动运行代码的过程的情况下将恢复内存。
答案 4 :(得分：0)
不要假设任何事情，在它上面运行一个内存分析器，看看它在做什么。
答案 5 :(得分：0)
如果是在Linux上，请检查'free'的输出，并专门检查'cached'ram的数量。如果您的开发工作包含大量磁盘I / O，它将使用它来缓存文件，并且您将看到很少“可用”但如果需要它仍然存在。出于所有实际目的，请考虑免费+缓存为可用。
'free'输出是从/ proc / meminfo中提取的，您可以在/ proc / $ pid / {maps，smaps}中获取有关正在运行的进程的更多详细信息
理论上，当您的进程退出时，它释放的任何内存都会被释放。你的流程正在退出吗？
答案 6 :(得分：0)
当我在大学时，我们使用了Borland C ++ Builder 6 IDE 它包括CodeGuard，它检查内存泄漏和其他内存相关问题。 我不确定这个选项是否仍适用于较新版本，但新版本的功能较少会很奇怪。
在linux上，如前所述，valgrind是一个很好的内存泄漏调试器。