在C或c++应用程序中出现内存泄漏是可以接受的吗?
如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的析构函数)，会怎样?只要内存消耗不随时间增长，那么当应用程序终止时(在Windows、Mac和Linux上)，是否可以信任操作系统为您释放内存?如果内存一直被使用，直到被操作系统释放，您会认为这是真正的内存泄漏吗?
如果是第三方库将这种情况强加给您，该怎么办?会拒绝使用第三方库，不管它有多好?
我只看到了一个实际的缺点，那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。
当前回答
理论上没有，实际情况要视情况而定。
这实际上取决于程序处理了多少数据，程序运行的频率以及它是否持续运行。
如果我有一个快速程序，读取少量数据进行计算并退出，那么就永远不会注意到一个小的内存泄漏。因为程序不会运行很长时间，并且只使用少量的内存，所以当程序存在时，泄漏将很小并被释放。
另一方面，如果我有一个处理数百万条记录并运行很长时间的程序，一个小的内存泄漏可能会在足够的时间内使机器停机。
对于有泄漏的第三方库，如果它们导致问题，要么修复库，要么找到更好的替代方案。如果不造成问题，这真的重要吗?
其他回答
Some great answers here. To add another perspective to this question, I'll address a case where memory leak is not only acceptable but desirable: in Windows drivers environment the developer provides a set of callbacks that are being run by the OS whenever required. One of the callbacks is a 'Shutdown' callback, which runs prior to system being shut off/restarted. Unlike standard situations, not only memory release is not necessary (system will be off in a moment), it's even discouraged - to make the shutdown as fast as possible and prevent the overhead of memory management.
即使您确定“已知的”内存泄漏不会造成严重破坏，也不要这样做。在最好的情况下，它会为你在不同的时间和地点犯下类似的、可能更严重的错误铺平道路。
对我来说，问这个问题就像问“我可以在凌晨3点没有人的时候闯红灯吗?”当然，在那个时候它可能不会造成任何麻烦，但它将为你在高峰时间做同样的事情提供一个杠杆!
许多人似乎都有这样的印象:一旦释放内存，它就会立即返回到操作系统，可以被其他程序使用。
这不是真的。操作系统通常以4KiB页面管理内存。malloc和其他类型的内存管理从操作系统获取页面，并在它们认为合适的时候对它们进行子管理。free()很可能不会将页面返回给操作系统，前提是您的程序稍后会误用更多内存。
我并不是说free()从不将内存返回给操作系统。这是有可能发生的，特别是当您正在释放大量内存时。但这并不能保证。
重要的事实是:如果不释放不再需要的内存，那么进一步的malloc必然会消耗更多的内存。但是如果先释放，malloc可能会重新使用释放的内存。
这在实践中意味着什么?这意味着如果你知道你的程序从现在开始不再需要更多的内存(例如它在清理阶段)，释放内存就不是那么重要了。但是，如果程序稍后可能分配更多内存，则应该避免内存泄漏——特别是那些可能重复发生的内存泄漏。
关于为什么在终止前释放内存是不好的，请参阅这条评论了解更多细节。
评论者似乎不理解调用free()并不会自动允许其他程序使用释放的内存。但这就是这个答案的全部意义!
因此，为了说服人们，我将演示一个例子，其中free()没有什么好处。为了便于计算，我假设操作系统以4000字节的页面管理内存。
Suppose you allocate ten thousand 100-byte blocks (for simplicity I'll ignore the extra memory that would be required to manage these allocations). This consumes 1MB, or 250 pages. If you then free 9000 of these blocks at random, you're left with just 1000 blocks - but they're scattered all over the place. Statistically, about 5 of the pages will be empty. The other 245 will each have at least one allocated block in them. That amounts to 980KB of memory, that cannot possibly be reclaimed by the operating system - even though you now only have 100KB allocated!
另一方面，您现在可以malloc() 9000多个块，而不会增加程序占用的内存量。
即使free()在技术上可以将内存返回给操作系统，它也可能不会这样做。Free()需要在快速操作和节省内存之间取得平衡。此外，一个已经分配了大量内存然后释放它的程序很可能会再次这样做。web服务器需要处理一个又一个的请求——保持一些“松弛”的可用内存是有意义的，这样你就不需要一直向操作系统请求内存了。
如果一直使用到main()的尾部，则根本不是泄漏(当然，假设有受保护的内存系统!)
事实上，在进程关闭时释放对象绝对是你能做的最糟糕的事情……操作系统必须将你创建的每一页回退。关闭文件句柄，数据库连接，当然，但释放内存是愚蠢的。
如果您的代码有任何内存泄漏，即使是已知的“可接受的”泄漏，那么使用任何内存泄漏工具来查找“真正的”泄漏将会非常麻烦。就像留下“可接受的”编译器警告会使查找新的“真正的”警告更加困难一样。
