是否存在“好”内存泄漏之类的东西？ [复制]答案

【问题标题】：Is there such a thing as a "good" memory leak? [duplicate]是否存在“好”内存泄漏之类的东西？ [复制]
【发布时间】：2010-09-24 08:21:32
【问题描述】：

可能重复：
Are memory leaks ever ok?

我在某处读到，在某些特殊情况下需要内存泄漏，但在极少数情况下实际上是一件好事。但我不记得具体是什么了！

有人知道或记得这样的论点吗？

谢谢，阿迪

【问题讨论】：

【解决方案1】：

我能想到的唯一需要内存泄漏的情况如下：

（除了第一个之外，它们都有点令人费解）

【讨论】：

好点，我以前做过。我在整个单元测试运行中运行了检漏仪，并且我故意从第一次测试中泄漏了一个块，以证明测试代码正确地使用了检漏仪。因此，0 个泄露的块是测试失败，当然是 2 个或更多。

【解决方案2】：

哇，我很想知道你是从哪里听说的。内存泄漏就是这样，内存的意外泄漏会浪费资源。我看不出有什么理由想要这种行为，除非你正在构建你希望你的竞争对手使用的软件（就像美国人对俄罗斯人所做的那样，他们让他们窃取管道控制软件）！

【讨论】：

【解决方案3】：

我能想到的唯一接近的事情是当您想要测试代码以处理内存不足的情况时。这对于没有交换空间的嵌入式系统很重要，因为内存不足是一种致命的情况。

如果您想通过自动化单元测试获得接近 100% 的代码覆盖率，您必须想办法让自动化单元测试中的特定分配请求失败（说起来容易做起来难）。

完成后，您需要为每个分配请求编写一个单元测试，以确保正确处理该分配的内存不足故障（大量工作）。

【讨论】：

执行此操作的通常方法 AFAIK 是将内存分配器替换为一个被操纵以提示失败的内存分配器。只要您的代码具有合理的确定性，测试就会告诉分配器“在 17 次分配中失败”，然后运行一些测试代码，您要测试的分配是它所做的第 17 次分配。耗时。
哦，你不会只使用 17，因为那时对被测代码的任何更改都可能通过将关键分配设置为 16 或 18 来逃避测试。您对从 1 到“分配器报告它不必失败”的所有 n 执行此操作。

【解决方案4】：

内存泄漏永远不会“正常”。有时您需要分配一块内存而不是释放它，因为稍后会需要它，但这不是内存泄漏。但是说内存泄漏之类的东西可以避免内存碎片就像说今天最好跳过工作而不打电话以避免迟到。

【讨论】：

【解决方案5】：

我从未听说过内存泄漏是件好事。

在现代操作系统中，它们几乎没有 5-10 年前那么糟糕。那时，在监管程序和内存泄漏方面做得更差的操作系统会导致内存永久丢失，直到操作系统重新启动。

这些天来，这不是一个真正的问题。因此，最常见的“内存泄漏”是当事情没有正确清理错误并退出程序时。当程序即将终止时，通常可以让内存保持未释放状态，因为当程序被操作系统拆除时，所有这些都会以任何方式重新释放。

当程序运行时，我想不出你会想要内存泄漏的原因。

【讨论】：

抱歉，5 年前？ IIRC，Windows XP SP1（2002 年发布）确实有每个进程的内存堆，并且不会永久泄漏用户分配的内存（除非您是 c 的设备驱动程序）。我认为你暴露了你的年龄；-p
5 年？那是很久以前的事了：-P

【解决方案6】：

如果您是一家托管公司，可以收取 $$$++ 用于服务器内存升级的费用。

【讨论】：

【解决方案7】：

@阿迪巴尔达：

从长远来看，泄漏对象消耗更多内存的问题将超过内存碎片问题。

【讨论】：

【解决方案8】：

如何避免内存碎片？这不是一个足够好的理由吗？

【讨论】：