最佳实践是始终释放所分配的空间，特别是在编写旨在在整个系统正常运行期间运行的内容时，即使在退出之前进行清理。

这是一个非常简单的规则。以无泄漏为目标进行编程，可以很容易地发现新的泄漏。你会卖给别人一辆你自己造的车吗?你知道它一熄火就会喷到地上?：）

清理函数中的一些if () free()调用是廉价的，为什么不使用它们呢?

我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。

在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。

这实际上取决于创建内存泄漏的对象的使用情况。 如果在使用该对象的应用程序的生命周期内多次创建该对象，那么使用这种方式是不好的。因为会有很多内存泄漏。 另一方面，如果我们有一个对象的实例，不消耗内存，只泄漏少量，那么这不是一个问题。

当应用程序运行时内存泄漏增加时，内存泄漏就是一个问题。

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

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…因为我知道"退出"只会让情况更糟。

从历史上看，在某些边缘情况下，它在某些操作系统上确实很重要。这些边缘情况在未来可能会存在。

Here's an example, on SunOS in the Sun 3 era, there was an issue if a process used exec (or more traditionally fork and then exec), the subsequent new process would inherit the same memory footprint as the parent and it could not be shrunk. If a parent process allocated 1/2 gig of memory and didn't free it before calling exec, the child process would start using that same 1/2 gig (even though it wasn't allocated). This behavior was best exhibited by SunTools (their default windowing system), which was a memory hog. Every app that it spawned was created via fork/exec and inherited SunTools footprint, quickly filling up swap space.