首先，让我们把定义更正一下。内存泄漏是指动态分配内存，例如使用malloc()，并且所有对内存的引用都在没有相应的free的情况下丢失。制作一个简单的方法是这样的:

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

注意，每次在while(1)循环中，分配1024(+开销)字节，并将新地址分配给vp;没有指向之前malloc 'Ed块的剩余指针。这个程序保证运行到堆用完为止，并且没有办法恢复任何malloc'ed内存。内存从堆中“泄漏”出来，再也看不见了。

你所描述的，听起来就像

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

你分配内存，使用它直到程序结束。这不是内存泄漏;它不会损害程序，并且当程序终止时，所有的内存将被自动清除。

一般来说，应该避免内存泄漏。首先，因为就像你头顶上的高度和飞机库里的燃料一样，已经泄漏且无法恢复的内存是无用的;其次，在一开始就正确编码，不泄漏内存，比后来发现内存泄漏要容易得多。

是的，内存泄漏可能是两害相权取其轻。虽然正确性很重要，但在执行完全内存释放时，性能或系统的稳定性可能会受到影响，并且释放内存和销毁对象所花费的风险和时间可能比仅仅退出进程更可取。

一般来说，在周围留下内存通常是不可接受的。理解代码运行的所有作用域是很困难的，在某些情况下，这可能导致泄漏成为灾难性的。

如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的析构函数)，会怎样?

在这种情况下，您的代码可能会移植到更大的项目中。这可能意味着您的对象的生命周期太长(它持续整个程序，而不仅仅是需要它的实例)，或者如果创建并销毁全局变量，它就会泄漏。

当应用程序终止时，是否可以信任操作系统为您释放内存

当一个短生命周期的程序创建大型c++集合(例如std::map)时，每个对象至少有2个分配。对CPU来说，遍历这个集合以销毁对象需要花费实时时间，而让对象泄漏并由操作系统清理具有性能优势。计数器，有一些资源没有被操作系统整理(例如共享内存)，并且不破坏代码中的所有对象会打开一些持有这些未释放资源的风险。

如果是第三方库将这种情况强加给您，该怎么办?

首先，我会为释放资源的close函数提出一个bug。是否可以接受的问题，是基于库提供的优势(成本、性能、可靠性)是否比使用其他库或自己编写更好。

一般来说，除非库可以重新初始化，否则我可能不会关心。

报告泄漏内存的可接受时间。

关闭期间的服务。这里需要在时间性能和正确性之间进行权衡。 一个破碎的无法被摧毁的物体。我已经能够检测到一个失败的对象(例如，由于异常被捕获)，当我尝试并销毁对象时，结果是挂起(持有锁)。 内存检查错误报告。

关闭期间的服务

如果操作系统即将关闭，所有资源将被清理。不执行正常进程关闭的优点是，用户在关闭时可以获得更快的性能。

破损的物品

在我的过去，我们发现了一个对象(并为该团队提出了一个缺陷)，如果它们在某些点崩溃，它们就会被破坏，该对象中的所有后续函数都会导致挂起。

尽管忽略内存泄漏是一种糟糕的做法，但关闭进程、泄漏对象及其内存比导致挂起更有效。

泄漏检查错误报告

一些泄漏检查器通过检测对象来工作，并以与全局变量相同的方式工作。它们有时会忽略另一个全局对象有一个有效的析构函数，在它们完成后调用，这将释放内存。

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

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.

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

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

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

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

即使您确定“已知的”内存泄漏不会造成严重破坏，也不要这样做。在最好的情况下，它会为你在不同的时间和地点犯下类似的、可能更严重的错误铺平道路。

对我来说，问这个问题就像问“我可以在凌晨3点没有人的时候闯红灯吗?”当然，在那个时候它可能不会造成任何麻烦，但它将为你在高峰时间做同样的事情提供一个杠杆!

如果一直使用到main()的尾部，则根本不是泄漏(当然，假设有受保护的内存系统!)

事实上，在进程关闭时释放对象绝对是你能做的最糟糕的事情……操作系统必须将你创建的每一页回退。关闭文件句柄，数据库连接，当然，但释放内存是愚蠢的。