如果您的代码有任何内存泄漏，即使是已知的“可接受的”泄漏，那么使用任何内存泄漏工具来查找“真正的”泄漏将会非常麻烦。就像留下“可接受的”编译器警告会使查找新的“真正的”警告更加困难一样。

如果您的代码有任何内存泄漏，即使是已知的“可接受的”泄漏，那么使用任何内存泄漏工具来查找“真正的”泄漏将会非常麻烦。就像留下“可接受的”编译器警告会使查找新的“真正的”警告更加困难一样。

我想，如果你正在编写一个打算泄漏内存的程序(即测试内存泄漏对系统性能的影响)，这是没有问题的。

随着时间的推移，我看到的“良性”泄漏的数量一只手就能数得过来。

所以我的答案是肯定的。

An example. If you have a singleton resource that needs a buffer to store a circular queue or deque but doesn't know how big the buffer will need to be and can't afford the overhead of locking or every reader, then allocating an exponentially doubling buffer but not freeing the old ones will leak a bounded amount of memory per queue/deque. The benefit for these is they speed up every access dramatically and can change the asymptotics of multiprocessor solutions by never risking contention for a lock.

我已经看到这种方法在具有非常明确的固定计数的事情上有很大的好处，例如每cpu工作窃取deques，并且在Hans Boehm的C/ c++保守垃圾收集器中用于保存单例/proc/self/maps状态的缓冲区中有较小的程度，用于检测根集等。

虽然从技术上讲这是一个漏洞，但这两种情况在大小上都是有限制的，并且在可增长的循环工作窃取deque情况下，可以获得巨大的性能优势，以换取队列内存使用量增加2的有界因子。

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

You have to first realize that there's a big difference between a perceived memory leak and an actual memory leak. Very frequently analysis tools will report many red herrings, and label something as having been leaked (memory or resources such as handles etc) where it actually isn't. Often times this is due to the analysis tool's architecture. For example, certain analysis tools will report run time objects as memory leaks because it never sees those object freed. But the deallocation occurs in the runtime's shutdown code, which the analysis tool might not be able to see.

尽管如此，仍然会有一些时候，您会遇到实际的内存泄漏，这些泄漏要么很难发现，要么很难修复。现在的问题是，是否可以将它们保留在代码中?

The ideal answer is, "no, never." A more pragmatic answer may be "no, almost never." Very often in real life you have limited number of resources and time to resolve and endless list of tasks. When one of the tasks is eliminating memory leaks, the law of diminishing returns very often comes in to play. You could eliminate say 98% of all memory leaks in an application in a week, but the remaining 2% might take months. In some cases it might even be impossible to eliminate certain leaks because of the application's architecture without a major refactoring of code. You have to weigh the costs and benefits of eliminating the remaining 2%.