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

No.

作为专业人士，我们不应该问自己“这样做是否合适?”，而应该问自己“这样做是否有一个好的理由?”“寻找内存泄漏是一种痛苦”并不是一个好的理由。

我喜欢把事情简单化。简单的规则是，我的程序应该没有内存泄漏。

这也让我的生活变得简单。如果我检测到内存泄漏，我会消除它，而不是通过一些复杂的决策树结构来确定它是否是“可接受的”内存泄漏。

它类似于编译器警告——警告对我的特定应用程序是致命的吗?也许不是。

但归根结底，这是一个职业纪律问题。容忍编译器警告和容忍内存泄漏是一个坏习惯，最终会给我带来麻烦。

举个极端的例子，外科医生把手术设备留在病人体内是可以接受的吗?

尽管移除设备的成本/风险可能会超过保留设备的成本/风险，并且可能在某些情况下它是无害的，但如果我在外科医生网站上看到这个问题，看到除了“不”之外的任何答案，这将严重削弱我对医疗行业的信心。

–

如果是第三方图书馆把这种情况强加给我，我会严重怀疑该图书馆的整体质量。这就像我试驾一辆车，发现其中一个杯托里有几个松动的垫圈和螺母——这本身可能不是什么大问题，但这表明我缺乏对质量的承诺，所以我会考虑其他选择。

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

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

退出应用程序的好处是:

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

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

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

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

我只看到了一个实际的缺点，那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。

If I understood correctly, you don't explicitly free memory (which can be freed because you still have a pointer) and rely on OS to free it during process termination. Though this may seem okay for simple program, consider the situation where your code is moved into a library and becomes a part of some resident daemon process running 24/7. Say this daemon spawns a thread each time it needs to do something useful using your code and say it spawns thousands of threads every hour. In this case you will get real memory leak.

不幸的是，这种情况在现实生活中并非不可能，一致的内存管理技术可能会使您的生活更轻松。

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

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

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

如果分配内存并一直使用到程序的最后一行，这就不是泄漏。如果您分配内存并忘记它，即使内存数量没有增长，这也是一个问题。已分配但未使用的内存可能导致其他程序运行速度变慢或根本不运行。