小内存泄漏是否重要?

lke*_*ler 27 memory-leaks

现在所有PC上的RAM通常都在千兆字节,我是否应该花时间寻找可能在我的程序中的所有小的(不增长的)内存泄漏?我说的是那些可能小于64字节的漏洞,甚至是一堆只有4字节的漏洞.

其中一些很难识别,因为它们不在我自己的代码中,但可能在第三方代码或开发工具的代码中,我甚至可能无法直接访问源代码.在这些情况下,它将涉及与这些产品的供应商进行长时间的沟通.

我在SO上看到了第一个内存泄漏问题:内存泄漏是否正常?而目前排名第一的答案是:现在投了85次,是:不.

但在这里,我谈的是小泄漏,可能需要进行大量的调试,研究和沟通才能追踪.

我只谈论一个简单的桌面应用程序.我知道在服务器上运行的应用程序必须尽可能紧密.

所以我真正要问的问题是,如果我知道我有一个泄漏的程序,每次运行时说40个字节,那有关系吗?

单滴!http://www.beholdgenealogy.com/img/single_drip.jpg


另请参阅我的后续问题:哪些操作系统会释放内存泄漏?


后记:我刚刚为我的程序开发购买了EurekaLog.

我发现 EurekaLog的作者Alexander(他应该知道这些事情)的一篇优秀文章,关于捕获内存泄漏.在那篇文章中,亚历山大非常简洁地陈述了我的问题的答案:

虽然应用程序中的任何错误总是很糟糕,但是存在一些错误类型,这些错误在某些环境中是不可见的.例如,内存或资源泄漏错误在客户端计算机上相对无害,并且可能在服务器上致命.

Ree*_*sey 47

这完全是个人决定.

但是,如果:

所以我真正要问的问题是,如果我知道我有一个泄漏的程序,每次运行时说40个字节,那有关系吗?

在这种情况下,我会说不.在程序结束时,内存将被回收,因此,如果它只是泄漏40个字节一次可执行的操作过程中,这实际上是毫无意义.

但是,如果它重复泄漏40个字节,那么每次执行某些操作时,这可能更有意义.应用程序运行时间越长,变得越重要.

但我会说,修复内存泄漏通常是值得的,即使泄漏是"毫无意义"的泄漏.内存泄漏通常是一些潜在问题的指标,因此理解和纠正泄漏通常会使您的程序随着时间的推移更加可靠.

  • +1实际理解问题(并回答它). (8认同)

Bri*_*ian 30

泄漏是错误.

您可能还有其他错误.

当您运送产品时,您运送已知的错误.当您选择哪个(已知的)错误"修复"而不是"随附"时,您可以根据修复的成本和风险与客户利益进行比较.

泄漏也不例外.如果在非服务器应用程序中不频繁的操作(例如,运行几分钟或几小时然后关闭的应用程序)发生的小泄漏,它可能是"正常",就像任何其他错误一样.

实际上,泄漏在一个重要方面可能有所不同,即如果您要运送库/ API,您真的应该修复它们,因为客户利益是巨大的(否则您的所有客户'继承'您的泄漏,并且将是打电话给你就像你现在要与第三方供应商交谈一样).


Ben*_*Cox 19

虽然我同意每一个小漏洞都会增加,但我不同意解决它总是最好的商业决策.

如果您拥有无状态遗留系统并且没有理解它的编码人怎么办?现在你在一个必须扩展的情况下使用它...并且在内存过量之前生成一个新实例并将它们交换出来要便宜100倍.

或者假设您有一个24x7全天候运行的批处理系统,但没有真正的用户.如果监视内存并告诉系统定期重启自己更便宜,为什么还要追捕泄漏?

我认为你应该努力尝试,但要务实做出决定的商业后果.

  • +1.大多数(我相信,每一个,但我都有一个开放的心态)决定有成本和收益.所有的决定都应该权衡这两个.过去的一个特定示例是服务器应用程序中的泄漏,我们认为这需要几周的时间来跟踪和修复.我们实现了"在安静时间自动重启服务器"解决方案,该解决方案运行良好.最好通知用户他们在上午12:10到12:20之间无法使用系统而不是花钱修理它.特别是因为它主要是一个9到5的业务. (6认同)
  • 有点实用主义. (5认同)

min*_*ang 10

不,这不要紧,但是,仅仅是如果,正如你所指出,内存泄漏不能重复的.内存泄漏不会随着程序的进展而增长通常是可以的.当进程终止时,最终将解决不增长的内存泄漏.

但是,很难证明观察到的内存泄漏没有增长; 你有足够的经验数据.实际上,许多大型程序(甚至用Java/C#编写)都有内存泄漏,但大多数都是非增长的泄漏.

说真的,我们不能没有内存泄漏,死锁,数据竞争.有这些错误本身是好的.只有当它杀死你的程序时,它才重要.

但是,我不同意你的意见:"记忆很便宜".这无法证明内存泄漏的合理性.这非常危险.


S.L*_*ott 5

是.泄漏很重要.如果您的应用程序以24x7x365运行并且每秒处理几千个事务,则几个字节会快速转换为千兆字节.

  • 如果我的应用程序只是一个桌面程序,当用户想要使用它时手动运行,那么它是否重要? (3认同)

Mar*_*ius 5

内存泄漏实际上取决于几件事:

  • 泄漏发生的频率
  • 每次丢失多少内存
  • 该计划将运行多长时间

例如,如果每次任务发生时丢失40个字节,并且该任务在程序启动时发生,则无人问津.如果每次程序启动时丢失40Mb,则应对其进行调查.如果您在视频或游戏引擎中每帧丢失40个字节,那么您应该研究一下,因为您每秒会损失1.2kB,一小时后您将丢失近4Mb.

这还取决于该计划将持续多久.例如,我有一个小型计算器应用程序,我打开,运行计算,然后再次关闭.如果该应用程序在运行中丢失4Mb,那么它并不重要,因为一旦我关闭它,操作系统将回收丢失的内存.如果之前提到的假设视频/游戏引擎每小时损失4Mb,并且它在一个大会的展位上运行一个演示单元,每天几个小时,那么我会调查它.

一个着名的内存泄漏的例子是Firefox,它在早期版本中丢失了大量内存.如果您的浏览器在10年前泄露了内存,那么您可能根本不在乎.您每天都关闭计算机,而在运行浏览器时,您一次只能打开一个页面.今天我只是让我的笔记本电脑进入待机状态,我从不关闭Firefox.它一次打开几个星期,我在任何给定时间至少打开10个标签.如果每次关闭选项卡时内存泄漏,那么现在将比10年前更大的泄漏,因此更重要.


a p*_*erd 5

内存泄漏是否正常?

当然,如果这是一个短暂的过程.

正如85分的答案所暗示的,长时间内存泄漏是有问题的.拿一个简单的桌面应用程序,例如 - 在版本3.x之前,你有没有注意到你需要它一段时间后重新启动Firefox以从缓慢恢复它?

至于短期,不,没关系.以CGI或PHP脚本为例,或者在~/bin目录中使用小的Perl三线程.如果你用C语言编写一个30行非循环应用程序,malloc()而不是一次调用,那么没有人会打电话给内存警察free().