如何阅读 Firefox“about:memory”正确吗？
在 Firefox 中（我猜是从 Firefox 4 开始），我们有 about:memory 页面。即使我非常熟悉 C/C++ 动态内存管理，我也不得不承认我真的不知道如何阅读该页面。
我希望 about:memory 能给我，作为 JavaScript/前端开发人员，一种更好的方法来检测/查找在 ECMAScript 和/或 DOM 脚本中创建的内存泄漏。我正在 Windows 7 和 Mac OS X Snow Leopard 系统上进行测试。
所以我有几个问题，希望有人能回答这些问题（如果您不确定，请不要猜测）。
- Windows 7
win32/privatebytes和内存使用情况之间的差异。
这真让我烦恼。如果我正在执行一些繁重的 ECMAScript/DOM 操作，则前一个值似乎会无限增加，而相比之下 Memory in use 一直“很小”。 这里哪个值真正有趣？看起来 win32 privatebytes 与您在任务管理器中看到的值相同。
内存映射和使用中的内存有什么区别？
我在谷歌上搜索了很长一段时间。有人说它表明正在使用的内存中有多少是碎片。详细来说这是什么意思？这是内存泄漏的直接指标吗？
如果有人可以稍微解释一下大多数值（或链接我找不到的资源），我会很高兴。但是，对我来说最有趣的是那些 win32 privatebytes 和浏览器内存使用之间的巨大差距。 Max OS X 似乎没有这些值的等价物，我猜这是因为内存管理系统根本不同。
In Firefox (I guess since Firefox 4) we have the about:memory page. Even if I'm quite familiar with C/C++ dynamic memory management, I have to admit I don't really know how to read that page.
I was hoping about:memory would give me, as JavaScript/front-end developer, a better way to detect/find memory leaks, created in ECMAScript and/or DOM scripting. I'm testing on a Windows 7 and a Mac OS X Snow Leopard system.
So I've got a few questions and hopefully someone can answer those (please don't guess if you are not sure).
- Windows 7 difference between
win32/privatebytesandMemory in use.
This really annoys me. If I'm doing some heavy ECMAScript/DOM operations, the former value seems to increase to no end, where in contrast Memory in use keeps being "smallish".
Which value is really interesting here? It looks like win32 privatebytes is the same value that you can see in your Task Manager.
- What is the difference between
Memory mappedandMemory in use?
I'm googling for quite a while on this one. Some people say it indicates how much of the memory in use is fragmented. What does that mean in detail? Is that a direct indicator for memory leaks?
I'd be happy if someone could explain most of the values just a little (or link a resource which I didn't find). But, most interesting for me is the big gap between those win32 privatebytes and the browsers memory usage. Max OS X does not seem to have an equivalent for those values, which I guess is because of a fundamental different memory management system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这个 mozilla 博客似乎解释得很好，如果没有，那么您可以找到了解的人的联系方式：
http://blog.mozilla.com/nnethercote/2011/05/23/a-better-aboutmemory-stage-1-75/
This mozilla blog seems to explain it quite well, and if not, then you've got the contact details of someone who would know:
http://blog.mozilla.com/nnethercote/2011/05/23/a-better-aboutmemory-stage-1-75/
您应该只关心浏览器实际使用的内存。由于内存碎片等原因，操作系统级别总是会分配更多的内存。但这确实是只有浏览器开发人员需要考虑的事情。如果您发现可重现的病态行为，请提交 Mozilla 错误（需要最小化测试用例）。但除此之外，您应该只确保您的代码不会囤积无法释放的对象（通过使用的内存可见）。
我不确定“内存映射”在新版本的
about:memory中是否可见，也许是在新名称下。我很确定你不应该关心它。这是分配有地址的内存量，只有操作系统级别才有意义。You should only care about the memory actually used by the browser. There will always be more memory allocated at the OS level, due to memory fragmentation etc. But that's really something that only browser developers need to think about. If you see a reproducible pathological behavior - file a Mozilla bug (minimized testcase needed). But other than that you should only make sure that your code doesn't hoard objects that cannot be released (which is visible by the memory used).
I'm not sure whether "memory mapped" is even visible in the new version of
about:memory, maybe under a new name. I'm pretty sure that you shouldn't care about it however. That's the amount of memory that has an address assigned to it, something that's only interesting on the OS level.回答线程标题中的一般问题，而不是似乎已解决的具体问题：
要查找讨论，请在 mozilla 代码中搜索措施名称，例如 http://mxr.mozilla.org/mozilla-central/search?string=heap-dirty ，选择“Hg Blame”链接，单击包含度量名称的行之前的链接 (它看起来像
@ changeset NNNNNN a6b3a22fbca7），然后单击错误链接。Answering the generic question in the thread's title, and not the specific questions, which seem to be resolved:
To find the discussion, search the mozilla code for the measure name, e.g. http://mxr.mozilla.org/mozilla-central/search?string=heap-dirty , select 'Hg Blame' link, click the link before the line with the measure's name (it looks like
<user>@<revid>), and click the changeset link (likechangeset NNNNNN a6b3a22fbca7) then click on the bug link.