在您的C或C应用程序中使用memory leak是否可以接受？
如果您分配一些内存并使用它直到应用程序中最后一行代码（例如，全局对象的析构函数），该怎么办？只要内存消耗不会随着时间的推移而增长，当您的应用程序终止时（在Windows，Mac和Linux上），是否可以信任操作系统为您释放内存？如果内存被连续使用直到它被操作系统释放，你甚至会认为这是一个真正的内存泄漏 .
如果第三方图书馆强迫你这样做怎么办？不管它有多么伟大，会拒绝使用第三方库吗？
我只看到一个实际的缺点，那就是这些良性泄漏会将内存泄漏检测工具显示为误报 .
30 回答
首先让我们的定义正确 . 内存泄漏是在动态分配内存时，例如使用
malloc()，并且所有对内存的引用都会丢失而没有相应的空闲内存 . 制作一个的简单方法是这样的：注意，每次while（1）循环时，都会分配1024（开销）字节，并将新地址分配给vp;没有剩余指向前面的malloc'ed块的指针 . 保证这个程序一直运行直到堆耗尽，并且没有办法恢复任何malloc的内存 . 内存从堆中“泄漏”，永远不会被再次看到 .
你所描述的，听起来像是
您分配内存，使用它直到程序终止 . 这不是内存泄漏;它不会损害程序，当程序终止时，所有内存都将自动清除 .
通常，您应该避免内存泄漏 . 首先，因为高于你的高度并在机库燃料回来，已经泄漏且无法恢复的记忆是无用的;第二，在开始时编码正确，而不是泄漏内存比在以后发现内存泄漏要容易得多 .
没有 .
作为专业人士，我们不应该问自己的问题是，“而是”有没有一个很好的理由去做这个？" And "追捕内存泄漏是一种痛苦“并不是一个好理由 .
我喜欢简单易懂 . 简单的规则是我的程序应该没有内存泄漏 .
这也让我的生活变得简单 . 如果我检测到内存泄漏，我会消除它，而不是通过一些复杂的决策树结构来确定它是否是“可接受的”内存泄漏 .
它与编译器警告类似 - 警告对我的特定应用程序是否致命？也许不吧 .
但这最终是专业纪律的问题 . 容忍编译器警告和容忍内存泄漏是一个坏习惯，最终会让我陷入困境 .
为了将事情发挥到极致，外科医生是否可以在患者体内留下一些操作设备？
虽然可能出现这样的情况，即移除该设备的成本/风险超过了将其丢弃的成本/风险，并且可能存在无害的情况，如果我在SurgeonOverflow.com上发布了这个问题除了“不”之外，还有任何答案，这会严重损害我对医学界的信心 .
如果第三方图书馆强迫我这样做，那将导致我严重怀疑图书馆的整体质量 . 这就好像我试驾开一辆车，并在其中一个杯架中发现了一些松散的垫圈和螺母 - 它本身可能不是什么大问题，但它描述了对质量缺乏承诺，所以我会考虑替代品 .
除非“使用”的内存量不断增长，否则我不认为它是内存泄漏 . 除非所需的内存量不断增长，否则有一些未释放的内存虽然不理想但不是一个大问题 .
理论上没有，在实践中它取决于 .
这实际上取决于程序正在处理的数据量，程序运行的频率以及程序是否在不断运行 .
如果我有一个快速程序读取少量数据进行计算并退出，则永远不会注意到小的内存泄漏 . 因为程序运行时间很长并且只使用少量内存，所以当程序存在时，泄漏会很小并释放 .
另一方面，如果我有一个处理数百万条记录并运行很长时间的程序，那么一个小的内存泄漏可能会给机器带来足够的时间 .
对于有泄漏的第三方库，如果它们导致问题，要么修复库，要么找到更好的替代方案 . 如果它没有引起问题，它真的重要吗？
很多人似乎都认为，一旦你释放了内存，它就会立即返回到操作系统，并可以被其他程序使用 .
事实并非如此 . 操作系统通常以4KiB页面管理存储器 .
malloc和其他种类的记忆管理从操作系统获取页面并在他们认为合适时对其进行子管理 . 在假设您的程序稍后会使用更多内存的情况下，free()很可能不会将页面返回到操作系统 .我不是说
free()永远不会将内存返回给操作系统 . 它可能发生，特别是如果你释放大量的内存 . 但是没有保证 .The important fact: 如果您没有释放不再需要的内存，则可以保证更多的malloc消耗更多的内存 . 但是如果你先释放，malloc可能会重新使用释放的内存 .
这在实践中意味着什么？这意味着如果你知道你的程序从现在开始不需要更多的内存（例如它在清理阶段），释放内存并不是那么重要 . 但是，如果程序稍后可能会分配更多内存，则应避免内存泄漏 - 尤其是可能重复发生的内存泄漏 .
另请参阅this comment以获取有关在终止错误之前释放内存的原因的更多详细信息 .
评论者似乎并不理解调用
free()不会自动允许其他程序使用释放的内存 . 但这就是这个答案的全部意义！因此，为了说服人们，我将展示一个free（）做得很少的例子 . 为了使数学易于理解，我假装操作系统管理4000字节页面的内存 .
假设您分配了一万个100字节的块（为简单起见，我将忽略管理这些分配所需的额外内存） . 这消耗1MB或250页 . 如果随后随机释放了9000个这样的块，那么你只剩下1000块 - 但它们遍布整个地方 . 据统计，大约有5个页面是空的 . 其他245将分别具有至少一个分配的块 . 这相当于980KB的内存，操作系统无法回收 - 即使你现在只分配了100KB！
另一方面，你可以现在malloc（）9000多个块，而不会增加程序占用的内存量 .
即使
free()技术上可以将内存返回给操作系统，也可能不会这样做 .free()需要在快速操作和节省内存之间取得 balancer . 此外，一个已经分配了大量内存然后释放它的程序可能会再次这样做 . Web服务器需要在请求后请求后处理请求 - 保留一些"slack"内存是有意义的，这样您就不需要一直询问操作系统内存 .在应用程序运行后清除操作系统没有任何概念上的错误 .
这实际上取决于应用程序以及它的运行方式 . 需要运行数周的应用程序中持续发生的泄漏必须得到解决，但是计算结果而没有太高内存需求的小工具应该不是问题 .
有许多脚本语言不会垃圾收集循环引用的原因......对于它们的使用模式，它不是一个实际的问题，因此与浪费的内存一样浪费资源 .
我相信答案是否定的，绝不允许内存泄漏，我有几个原因，我没有看到明确说明 . 这里有很好的技术答案，但我认为真正的答案取决于更多的社会/人类原因 .
（首先，请注意，正如其他人所提到的，真正的泄漏是当你的程序在任何时候都失去了它已经分配的内存资源的跟踪 . 在C中，这发生在你指向一个指针并让指针离开范围而没有做a
free()首先 . ）The important crux of your decision here is habit. 当您使用指针语言进行编码时，您将会大量使用指针 . 指针很危险;它们是向代码中添加各种严重问题的最简单方法 .
当你're coding, sometimes you'重新开始时，有时你会在自动驾驶仪上重新编码 . The autopilot effect doesn't differentiate between one-off code and a module in a larger project. During those times, the habits you establish are what will end up in your code base.
所以不，永远不要让内存泄漏的原因与你改变车道时仍应检查盲点的原因相同，即使你现在是路上唯一的车 . During times when your active brain is distracted, good habits are all that can save you from disastrous missteps.
除了“习惯”问题之外，指针很复杂，通常需要大量的脑力才能在心理上进行跟踪 . 当你使用指针时，最好不要“浑水”，特别是当你刚接触编程时 .
还有更多的社交方面 . 通过正确使用
malloc()和free()，任何查看代码的人都会感到轻松自在;但是，他们会立即怀疑有问题 .Maybe you've worked out that the memory leak doesn't hurt anything in this context, but every maintainer of your code will have to work that out in his head too when he reads that piece of code. 通过使用
free()，您甚至无需考虑问题 .最后，编程是将一个过程的心理模型写成一种明确的语言，这样一个人和一台计算机就能完全理解所述过程 . A vital part of good programming practice is never introducing unnecessary ambiguity.
智能编程灵活且通用 . 错误的编程是模棱两可的 .
我认为在你的情况下答案可能是没关系 . 但你肯定需要记录内存泄漏是一个有意识的决定 . 您不希望维护程序员出现，将您的代码插入函数内，并将其调用一百万次 . 因此，如果您确定泄漏是可以的，那么您需要记录它（大写字母），以便将来可能需要处理该程序的任何人 .
如果这是第三方库，您可能会被困 . 但绝对记录发生此泄漏 .
但基本上如果内存泄漏是一个已知的数量，如512 KB缓冲区或其他东西，那么这是一个非问题 . 如果内存泄漏持续增长，就像每次调用库调用时，内存增加了512KB并且没有释放，那么您可能会遇到问题 . 如果您记录并控制呼叫执行的次数，则可以进行管理 . 但是你真的需要文档，因为512并不多，512个超过一百万个电话是很多 .
您还需要检查操作系统文档 . 如果这是一个嵌入式设备，可能会有一些操作系统无法从退出的程序中释放所有内存 . 我不确定，也许这不是真的 . 但值得研究 .
我'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 . 例如，一个程序进行单个分配或一系列分配以加载它将在其整个生命周期中使用的数据集，而不需要释放任何东西 . 在一个具有非常动态内存要求的大型程序的更常见的情况下（想想一个Web浏览器），显然你应该释放内存，当用户选择点击"exit"时，没有理由释放任何内容，这样做实际上对于用户体验 .
为什么？释放内存需要触摸内存 . 即使你的系统的malloc实现没有将元数据存储在分配的内存块附近，你也可能会走向递归结构，只是为了找到你需要释放的所有指针 .
现在，假设您的程序使用了大量数据，但暂时没有触及大部分数据（同样，Web浏览器也是一个很好的例子） . 如果用户运行了大量应用程序，那么很大一部分数据可能已经交换到磁盘 . 如果您只是退出（0）或从主页返回，它会立即退出 . 出色的用户体验 . 如果您在尝试释放所有内容时遇到麻烦，您可能会花费5秒或更长时间将所有数据交换回来，然后立即将其丢弃 . 浪费用户的时间 . 浪费笔记本电脑的电池寿命 . 浪费在硬盘上 .
这不仅仅是理论上的 . 每当我发现自己加载的应用程序太多并且磁盘开始颠簸时，我甚至不会考虑点击“退出” . 我尽可能快地到达终端并键入killall -9 ...因为我知道“退出”会让情况变得更糟 .
我确信有人可以说出是的理由，但不会是我 . 而不是拒绝，我会说这不应该是一个是/否的问题 . 有办法管理或包含内存泄漏，许多系统都有它们 .
在离开地球的设备上有NASA系统可以为此做出规划 . 系统将每隔一段时间自动重启，以便内存泄漏不会对整个操作造成致命影响 . 只是遏制的一个例子 .
如果您分配内存并使用它直到程序的最后一行，那不是泄漏 . 如果您分配内存并忘记它，即使内存量没有增长，这也是一个问题 . 分配但未使用的内存可能会导致其他程序运行速度变慢或根本不运行 .
我可以一方面指望一段时间以来我所看到的“良性”泄漏的数量 .
所以答案是非常合格的 .
一个例子 . 如果你有一个单独的资源，需要一个缓冲区来存储循环队列或双端队列，但不知道缓冲区需要多大，并且无法承担锁定或每个读取器的开销，那么分配一个指数倍增的缓冲区但是不释放旧的将每个队列/双端队列泄漏有限的内存量 . 这些的好处是它们可以显着加快每次访问的速度，并且可以改变多处理器解决方案的渐近性，而不会冒着争用锁的风险 .
我已经看到这种方法非常有利于具有非常明确固定计数的事物，例如每CPU工作窃取deques，以及用于保持Hans Boehm的保守垃圾收集器中的单一状态的缓冲区的程度要小得多 . C / C，用于检测根集等 .
虽然在技术上是泄漏，但这两种情况都是有限的，并且在可增长的循环工作窃取案例中，有一个巨大的性能胜利，以换取队列的内存使用增加2的有限因素 .
它真的不是泄漏，如果它是有意的，它不是一个问题，除非它有大量的内存，或者可能会成长为一个大量的内存 . 在程序的生命周期内不清除全局分配是相当常见的 . 如果泄漏是在服务器或长时间运行的应用程序中，随着时间的推移增长，那么它就是一个问题 .
如果在程序开头分配了一堆堆，并且在退出时没有释放它，那本身就不是内存泄漏 . 内存泄漏是指程序循环遍历代码段，并且该代码分配堆然后“丢失跟踪”它而不释放它 .
实际上，没有必要在你之前调用free（）或delete出口 . 当进程退出时，操作系统将回收它的所有内存（POSIX就是这种情况 . 在其他操作系统上 - 尤其是嵌入式操作系统 - YMMV） .
我编码的唯一警告可能会变成内存泄漏 .
这是特定领域的，几乎不值得回答 . 用你的怪物头 .
航天飞机操作系统：不，不允许内存泄漏
快速开发概念验证代码：修复所有那些内存泄漏是浪费时间 .
并且存在一系列中间情况 .
延迟产品发布以解决除了最糟糕的内存泄漏之外的所有机会成本（$$$）通常使任何“草率或不专业”的感觉相形见绌 . 你的老板付钱让你为他赚钱，而不是为了获得温暖，模糊的感觉 .
您必须首先意识到感知到的内存泄漏与实际内存泄漏之间存在很大差异 . 非常频繁的分析工具会报告许多红色鲱鱼，并将某些东西标记为泄漏（内存或资源，如手柄等）实际上并非如此 . 通常这是由于分析工具的架构 . 例如，某些分析工具会将运行时对象报告为内存泄漏，因为它永远不会看到这些对象被释放 . 但是重新分配发生在运行时的关闭代码中，分析工具可能无法看到 .
话虽如此，仍然有时候你会发现实际的内存泄漏很难找到或很难解决 . 所以现在问题变成是将它们留在代码中了吗？
理想的答案是“不，永远不会” . 一个更务实的答案可能是“不，几乎从不” . 在现实生活中，您经常需要有限的资源和时间来解决无尽的任务列表 . 当其中一项任务是消除内存泄漏时，收益递减规律经常会发挥作用 . 您可以在一周内消除98％的应用程序内存泄漏，但剩下的2％可能需要数月 . 在某些情况下，由于应用程序的体系结构没有重复的代码重构，甚至可能无法消除某些泄漏 . 您必须权衡消除剩余2％的成本和收益 .
在这种问题中，上下文就是一切 . 我个人不能忍受泄漏，在我的代码中，如果他们突然出现，我会竭尽全力修复它们，但是修复泄漏并不总是值得的，当人们按时付钱给我时我偶尔会付钱给我他告诉他们，在我们的代码中修复漏洞对我来说是不值得的 . 让我给你举个例子：
我正在试验一个项目，做一些工作并修复很多错误 . 在我跟踪并完全理解的应用程序初始化期间发生了泄漏 . 正确地修复它需要一天左右的时间来重构一段功能代码 . 我本可以做一些hacky（比如将值填充到全局并 grab 它，我知道它已经不再用于释放了），但这会让下一个不得不触摸代码的人感到更加困惑 .
就个人而言，我不会在第一时间编写代码，但我们大多数人都不会总是在原始设计良好的代码库上工作，有时你必须务实地看待这些事情 . 修复150字节泄漏所花费的时间可以用来进行算法改进，减少兆字节的内存 .
最终，我决定泄漏150个字节的应用程序，使用大约一个ram并在专用机器上运行是不值得修复它，所以我写了一条评论说它被泄露，需要改变什么来修复它，以及为什么它在当时不值得 .
虽然大多数答案都集中在真正的内存泄漏上（这是不可能的，因为它们是编码草率的标志），但这部分问题对我来说更有趣：
如果使用了相关的内存，则无法在程序结束前释放它 . 免费是由程序退出还是由操作系统完成无关紧要 . 只要记录下来，这样改变就不会引入真正的内存泄漏，并且只要图片中没有涉及C析构函数或C清理函数 . 可能通过泄漏的
FILE对象显示未关闭的文件，但缺少fclose（）也可能导致缓冲区无法刷新 .所以，回到原来的情况，恕我直言就好了，以至于Valgrind，最强大的泄漏探测器之一，会对待这样的只有在要求时泄漏 . 在Valgrind上，当你在不事先释放它的情况下覆盖指针时，它会被视为内存泄漏，因为它更有可能再次发生并导致堆无限增长 .
然后，没有可以访问的nfreed内存块 . 人们可以确保在出口处释放所有这些，但这本身就是浪费时间 . 关键是如果他们以前可以被释放 . 在任何情况下，降低内存消耗都很有用 .
即使您确定您的“已知”内存泄漏不会造成严重破坏，也不要这样做 . 充其量，它将为您在不同的时间和地点制造类似且可能更严重的错误铺平道路 .
对我来说，问这就像质疑“我可以在早上凌晨3点打破红灯时没有人在身边吗？” . 当然，它可能不会造成任何麻烦，但它会为你在高峰时段做同样的事情提供杠杆！
我想如果您正在编写一个旨在泄漏内存的程序（即测试内存泄漏对系统性能的影响），那就没问题了 .
我很惊讶地发现内存泄漏实际上有很多不正确的定义 . 没有具体的定义，关于它是否是坏事的讨论将无处可去 .
正如一些评论家正确指出的那样，只有当进程分配的内存超出范围到进程不再能够引用或删除它时，才会发生内存泄漏 .
grab 越来越多内存的过程不一定会泄露 . 只要它能够引用和释放该内存，那么它仍然处于该过程的明确控制之下并且没有泄露 . 这个过程可能设计得很糟糕，特别是在内存有限的系统环境中，但这与泄漏不同 . 相反，即使泄漏的内存量很小，丢失32字节缓冲区的范围仍然是泄漏 . 如果您认为这是无关紧要的，请等到有人在您的库调用周围包装算法并将其调用10,000次 .
我认为没有任何理由允许你自己的代码泄漏，无论多么小 . 现代编程语言（如C和C）竭尽全力帮助程序员防止此类泄漏，并且很少有充分的理由不采用良好的编程技术 - 特别是在与特定语言工具结合使用时 - 以防止泄漏 .
对于现有或第三方代码，您对质量或进行更改的能力的控制可能非常有限，根据泄漏的严重程度，您可能会被迫接受或采取缓解措施，例如定期重新启动流程以减少泄漏的影响 .
可能无法更改或替换现有（泄漏）代码，因此您可能必须接受它 . 但是，这与声明它没关系不一样 .
我想你已经回答了自己的问题 . 最大的缺点是它们如何干扰内存泄漏检测工具，但我认为这种缺点对某些类型的应用程序来说是一个巨大的缺点 .
我使用的遗留服务器应用程序应该是坚如磐石的但是它们有漏洞而且全局变量会妨碍内存检测工具 . 这是一个大问题 .
在贾里德·戴蒙德（Jared Diamond）的“崩溃”一书中，作者想知道这个家伙在减少复活节岛上最后一棵树的想法，这棵树是为了建造独木舟离开岛屿而需要的 . 我很想知道很多年前第一个全局被添加到我们的代码库中的那一天 . 那天应该被 grab 了 .
我发现像这样的所有场景问题都有同样的问题：程序发生变化时会发生什么，突然发现内存泄漏很少被调用一千万次，而程序结束时又处于不同的位置，所以这很重要？如果它在库中，那么记录库维护者的错误，不要在你自己的代码中泄漏 .
我会回答不 .
从理论上讲，操作系统会在你离开后弄清楚（现在这很粗鲁，但由于计算机没有感觉，因此可以接受） . 但是，您无法预测程序运行时可能出现的每种情况 . 因此（除非您能够对某些行为进行正式证明），从专业角度来看，创建内存泄漏是不负责任和邋 . 的 .
如果第三方组件泄漏内存，这是一个非常强烈的反对使用它的论据，不仅因为它即将产生影响，而且还因为它表明程序员工作不稳定，这也可能影响其他指标 . 现在，在考虑遗留系统时，这很困难（考虑网页浏览组件：据我所知，它们都会泄漏内存）但它应该是常态 .
从历史上看，它在一些边缘情况下对某些操作系统很重要 . 这些边缘情况将来可能存在 .
这是一个例子，在Sun 3时代的SunOS上，如果一个进程使用了exec（或者更传统的是fork然后执行exec），则会出现问题，后续的新进程将继承与父进程相同的内存占用并且无法收缩 . 如果父进程分配了1/2 gig的内存并且在调用exec之前没有释放它，则子进程将开始使用相同的1/2 gig（即使它没有被分配） . SunTools（他们的默认窗口系统）最好地展现了这种行为，这是一种记忆困难 . 它产生的每个应用程序都是通过fork / exec创建的，并继承了SunTools的足迹，迅速填补了交换空间 .
这已经讨论过ad nauseam . 底线是内存泄漏是一个错误，必须修复 . 如果第三方库泄漏内存，它会让人怀疑它还有什么问题，不是吗？如果你正在制造汽车，你会使用偶尔会漏油的发动机吗？毕竟，其他人制造了引擎，所以它解决它，对吗？
通常，独立应用程序中的内存泄漏并不是致命的，因为它会在程序退出时被清除 .
对于设计为不退出的服务器程序，您如何处理？
如果您是那种不设计和实现资源分配和正确发布的代码的程序员，那么我不希望与您或您的代码有任何关系 . 如果你不在乎清理你的泄漏内存，你的锁怎么样？你还把它们挂在那里吗？你是否在各种目录中留下了一小撮临时文件？
泄漏那个记忆并让程序清理它？不，绝对不是 . 这是一个坏习惯，导致错误，错误和更多错误 .
Clean up after yourself. Yo momma don't work here no more.
作为一般规则，如果你有内存泄漏，你觉得你无法避免，那么你需要更加思考对象所有权 .
但是对于你的问题，简而言之我的回答是在 生产环境 代码中，是的 . 在开发过程中，没有 . 这似乎是倒退，但这是我的理由：
在你描述的情况下，内存一直保持到程序结束，完全可以不释放它 . 一旦您的流程退出，操作系统仍会清理 . 实际上，它可能会让用户体验更好：在我参与过的游戏中，程序员认为在退出之前释放所有内存会更加清晰，导致程序关闭需要半分钟！一个名为exit（）的快速更改使该过程立即消失，并将用户放回到他想要的桌面 .
但是，你对调试工具是正确的：他们会抛出一个合适的，所有的误报可能会让你找到真正的内存泄漏 . 因此，总是编写释放内存的调试代码，并在发货时禁用它 .
不，你不应该有操作系统为你清理的泄漏 . 原因（就我可以检查的上面的答案中没有提到的）是你永远不会知道 when your main() will be re-used as a function/module in another program . 如果你的main（）成为另一个人的软件中经常被调用的函数 - 这个软件会有一个内存泄漏，随着时间的推移会占用内存 .
KIV
我同意vfilby - 这取决于 . 在Windows中，我们将内存泄漏视为相对严重的错误 . 但是，它在很大程度上取决于组件 .
例如，对于运行很少且在有限时间内运行的组件，内存泄漏并不严重 . 这些组件运行，执行该工作，然后退出 . 当他们退出时，他们的所有记忆都被隐含地释放了 .
但是，服务或其他长期运行组件（如shell）中的内存泄漏非常严重 . 原因是随着时间的推移，这些错误会“窃取”内存 . 恢复此功能的唯一方法是重新启动组件 . 大多数人不知道如何重新启动服务或shell - 所以如果他们的系统性能受损，他们只是重新启动 .
所以，如果你有泄漏 - 用两种方式评估其影响
了解您的软件和用户体验 .
对系统（和用户）而言是节俭的系统资源 .
修复对维护和可靠性的影响 .
在其他地方引起回归的可能性 .
Foredecker