我刚开始在C++中尝试使用SDL,我认为定期检查内存泄漏可能是早期形成的好习惯.
考虑到这一点,我一直在通过Valgrind运行我的'Hello world'程序以捕获任何泄漏,虽然除了最基本SDL_Init()和SDL_Quit()语句之外我已经删除了所有内容,但Valgrind仍然报告丢失了120个字节并且仍然可以访问77k.
我的问题是:内存泄漏是否有可接受的限制,或者我应该努力使我的所有代码完全无泄漏？
小心Valgrind没有在测量中发现误报.
许多内存分析器的天真实现将丢失的内存标记为泄漏,而实际上并非如此.
也许阅读维基百科关于Purify文章的外部链接部分的一些论文.我知道Purify附带的文档描述了几种情况,在尝试检测内存泄漏时会出现误报,然后继续描述Purify用于解决问题的方法.
顺便说一下,我不以任何方式与IBM有任何关系.我刚刚广泛使用Purify并保证其有效性.
编辑:这是一篇关于内存监控的优秀介绍性文章.这是Purify的具体内容,但对内存错误类型的讨论非常有趣.
HTH.
干杯,
抢
你必须小心"内存泄漏"的定义.在第一次使用时分配一次并在程序退出时释放的东西有时会被泄漏检测器显示出来,因为它在第一次使用之前就开始计数了.但这不是泄漏(虽然它可能是糟糕的设计,因为它可能是某种全球性的).
要查看给定的代码块是否泄漏,您可以合理地运行一次,然后清除泄漏检测器,然后再次运行(这当然需要对泄漏检测器进行编程控制).每次运行程序"泄漏"的事情通常无关紧要.每次执行时"泄漏"的事情通常最终都很重要.
我很少发现在这个指标上达到零很难,这相当于观察蠕变内存使用而不是丢失块.我有一个库,它有如此繁琐,有缓存和UI家具等等,我只是运行我的测试套件三次,并忽略任何"泄漏",这不会发生在三个块的倍数.我仍然抓住了所有或几乎所有真正的泄漏,并分析了棘手的报告,一旦我得到了悬而未决的果实.当然,为此目的使用测试套件的缺点是:(1)您只能使用不需要新进程的部分,以及(2)您发现的大多数泄漏都是测试代码的错误,而不是图书馆代码......
与内存泄漏(以及其他粗心问题)一起生活是最好的(在我看来)非常糟糕的编程.最坏的情况是它使软件无法使用.
您应该首先避免引入它们并运行您和其他人提到的工具来尝试检测它们.
避免草率编程 - 已经有足够的坏程序员 - 世界不需要另一个.
编辑
我同意 - 许多工具可以提供误报.
如果您真的担心内存泄漏,则需要进行一些计算.
您需要测试您的应用程序,如一小时,然后计算泄漏的内存.这样,您将获得泄漏的内存字节/分钟值.
现在,您需要估算程序会话的平均长度.例如,对于notepad.exe,15分钟听起来对我来说是一个很好的估计.
如果(平均会话长度)*(泄漏字节/分钟)> 0.3*(通常由您的进程占用的内存空间),那么您可能应该做更多努力来减少内存泄漏.我只是编了0.3,用常识来确定你可以接受的门槛.
请记住,作为程序员的一个重要方面是作为软件工程师,而工程师通常会选择两个或更多不良选项中最差的选项.当您需要测量实际选项的糟糕程度时,数学总是很方便.
对于桌面应用程序,小内存泄漏不是一个真正的问题.对于服务(服务器),不可接受内存泄漏.
当程序卸载时,大多数操作系统(包括Windows)将返回程序的所有已分配内存.这包括程序本身可能已丢失的任何内存.
鉴于此,我通常的理论是在启动期间泄漏内存是完全正常的,但在运行时不能正常.
所以真的问题不在于你是否泄漏任何内存,如果你在程序的运行时间不断泄漏那么就是这样.如果你使用你的程序一段时间,无论你做什么它都会丢失120个字节而不是增加,我会说你做得很好.继续.
京公网安备 11010802040832号 | 京ICP备19059560号-6 