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

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

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

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

I'm going to give the unpopular but practical answer that it's always wrong to free memory unless doing so will reduce the memory usage of your program. For instance a program that makes a single allocation or series of allocations to load the dataset it will use for its entire lifetime has no need to free anything. In the more common case of a large program with very dynamic memory requirements (think of a web browser), you should obviously free memory you're no longer using as soon as you can (for instance closing a tab/document/etc.), but there's no reason to free anything when the user selects clicks "exit", and doing so is actually harmful to the user experience.

为什么?释放内存需要接触内存。即使您的系统的malloc实现碰巧没有在分配的内存块附近存储元数据，您也可能会遍历递归结构，只是为了找到所有需要释放的指针。

Now, suppose your program has worked with a large volume of data, but hasn't touched most of it for a while (again, web browser is a great example). If the user is running a lot of apps, a good portion of that data has likely been swapped to disk. If you just exit(0) or return from main, it exits instantly. Great user experience. If you go to the trouble of trying to free everything, you may spend 5 seconds or more swapping all the data back in, only to throw it away immediately after that. Waste of user's time. Waste of laptop's battery life. Waste of wear on the hard disk.

这不仅仅是理论上的。每当我发现自己加载了太多的应用程序，磁盘开始抖动时，我甚至不会考虑点击“退出”。我以最快的速度到达一个终端，输入killall -9…因为我知道"退出"只会让情况更糟。

规则很简单:如果你用完了一些内存，就清理它。 有时，即使我们稍后需要一些实例，但我们注意到我们会大量使用内存，所以它会影响性能，因为交换到磁盘，我们可以将数据存储到磁盘文件中，然后重新加载它们，有时这种技术会优化你的程序。

在程序的最后一行省略释放内存是完全可以接受的，因为释放它不会对任何事情产生影响，因为程序再也不需要内存了。

在这类问题中，语境就是一切。就我个人而言，我不能忍受漏洞，在我的代码中，如果它们突然出现，我就会竭尽全力去修复它们，但修复漏洞并不总是值得的，当人们按小时支付我的报酬时，我有时会告诉他们，我的费用不值得我修复他们代码中的漏洞。让我给你们举个例子:

I was triaging a project, doing some perf work and fixing a lot of bugs. There was a leak during the applications initialization that I tracked down, and fully understood. Fixing it properly would have required a day or so refactoring a piece of otherwise functional code. I could have done something hacky (like stuffing the value into a global and grabbing it some point I know it was no longer in use to free), but that would have just caused more confusion to the next guy who had to touch the code.

就我个人而言，我一开始就不会以这种方式编写代码，但我们大多数人并不总是在设计良好的原始代码库上工作，有时你必须务实地看待这些事情。修复150字节泄漏所花费的时间可以用来改进算法，从而减少兆字节的内存。

最终，我决定为一个使用大约1g内存并运行在专用机器上的应用程序泄露150个字节不值得修复，所以我写了一条评论说它被泄露了，为了修复它需要改变什么，以及为什么当时不值得。

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

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

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.

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