我想以你的情况，答案可能是没关系。但是您肯定需要记录内存泄漏是一个有意识的决定。你不希望一个维护程序员出现，把你的代码放到一个函数中，然后调用它一百万次。因此，如果您决定泄漏是可以接受的，那么您需要为将来可能不得不在该程序上工作的任何人记录它(用大写字母)。

如果这是一个第三方库，你可能会被困住。但是一定要记录泄漏的发生。

但基本上，如果内存泄漏是一个已知的数量，比如512 KB的缓冲区，那么它就不是问题。如果内存泄漏持续增长，比如每次调用库调用时，内存都会增加512KB，但没有释放，那么可能有问题。如果您记录它并控制调用执行的次数，那么它可能是可管理的。但是你真的需要文档，因为虽然512不是很多，但是512超过一百万次调用就很多了。

此外，您还需要检查您的操作系统文档。如果这是一个嵌入式设备，那么操作系统可能不会从退出的程序中释放所有内存。我不确定，也许这不是真的。但这是值得研究的。

当应用程序关闭时，可以认为最好不要释放内存。

理论上，操作系统应该释放应用程序使用的资源，但总有一些资源是这个规则的例外。所以要小心。

退出应用程序的好处是:

操作系统只释放一个块，而不是很多很多小块。这意味着关机速度要快得多。尤其是在内存管理缓慢的Windows上。

只是退出的坏处其实有两点

很容易忘记释放操作系统没有跟踪的资源，或者操作系统可能会等待一段时间才释放。一个例子是TCP套接字。 内存跟踪软件将报告在退出时未释放的所有内容为泄漏。

因此，您可能希望有两种关机模式，一种是针对最终用户的快速且不友好的关机模式，另一种是针对开发人员的缓慢且彻底的关机模式。只是要确保两者都测试:)

一般情况下，如果遇到无法避免的内存泄漏，则需要更加认真地考虑对象所有权问题。

但对于你的问题，我的回答是在产品代码中，是的。在开发过程中，没有。这听起来可能有些倒退，但我的理由是:

In the situation you describe, where the memory is held until the end of the program, it's perfectly okay to not release it. Once your process exits, the OS will clean up anyway. In fact, it might make the user's experience better: In a game I've worked on, the programmers thought it would be cleaner to free all the memory before exiting, causing the shutdown of the program to take up to half a minute! A quick change that just called exit() instead made the process disappear immediately, and put the user back to the desktop where he wanted to be.

但是，您对调试工具的看法是正确的:它们会突然发作，而且所有的假阳性可能会使查找真正的内存泄漏变得很痛苦。正因为如此，总是编写释放内存的调试代码，并在发布时禁用它。

不，你不应该有漏洞，操作系统会为你清理。原因(据我所知，在上面的答案中没有提到)是你永远不知道什么时候你的main()会在另一个程序中作为函数/模块被重用。如果你的main()在其他人的软件中经常被调用，那么这个软件就会有内存泄漏，随着时间的推移会消耗内存。

KIV

我看到了和所有场景问题一样的问题，比如:当程序改变时，会发生什么?突然，这个小内存泄漏被调用了1000万次，而程序的结尾在不同的地方，所以它很重要?如果它在库中，那么请向库维护者记录错误，不要在您自己的代码中泄漏。

在以前，我可能会说是的，在你的程序中让一些内存泄漏有时是可以接受的(它仍然是快速原型)，但现在有了5到6次的经验，即使是跟踪最小的泄漏也会发现一些真正严重的功能错误。在数据实体的生命周期还不清楚的情况下，让程序发生泄漏，显示出严重缺乏分析。总之，了解程序中发生了什么总是一个好主意。