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

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.

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

理论上没有，实际情况要视情况而定。

这实际上取决于程序处理了多少数据，程序运行的频率以及它是否持续运行。

如果我有一个快速程序，读取少量数据进行计算并退出，那么就永远不会注意到一个小的内存泄漏。因为程序不会运行很长时间，并且只使用少量的内存，所以当程序存在时，泄漏将很小并被释放。

另一方面，如果我有一个处理数百万条记录并运行很长时间的程序，一个小的内存泄漏可能会在足够的时间内使机器停机。

对于有泄漏的第三方库，如果它们导致问题，要么修复库，要么找到更好的替代方案。如果不造成问题，这真的重要吗?

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

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

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

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

这是一个非常特定的领域，几乎不值得回答。动动你的脑袋。

航天飞机操作系统:不，不允许内存泄漏 快速开发概念验证代码:修复所有这些内存泄漏是浪费时间。

还有一系列的中间情况。

延迟产品发布以修复除最严重内存泄漏外的所有内存泄漏的机会成本($$$)通常会让“草率或不专业”的感觉相形见绌。你的老板付钱给你是为了给他赚钱，而不是为了得到温暖、模糊的感觉。

不，它们不是可以的，但是我已经实现了一些分配器、内存转储器和泄漏检测器，并且发现从实用的角度来看，允许人们将这样的分配标记为“就泄漏报告而言，不是泄漏”是很方便的……

这有助于使泄漏报告更有用……不要充斥着“静态范围内的动态分配不被程序退出释放”

也许是在细枝末节:如果您的应用程序运行在UNIX上，可能会变成僵尸怎么办?在这种情况下，内存不会被操作系统回收。所以我说你应该在程序退出之前重新分配内存。