查找JavaScript的内存泄漏铬 [英] Finding JavaScript memory leaks with Chrome

问题描述

我已经创建，创建一个视图骨干，附加一个处理程序的事件，并实例化一个用户定义的类一个非常简单的测试案例。我相信，通过点击此示例中的删除按钮，一切都将被清理，应该没有内存泄漏。

I've created a very simple test case that creates a Backbone view, attaches a handler to an event, and instantiates a user-defined class. I believe that by clicking the "Remove" button in this sample, everything will be cleaned up and there should be no memory leaks.

一个为code的jsfiddle是在这里： http://jsfiddle.net/4QhR2/

A jsfiddle for the code is here: http://jsfiddle.net/4QhR2/

// scope everything to a function
function main() {

    function MyWrapper() {
        this.element = null;
    }
    MyWrapper.prototype.set = function(elem) {
        this.element = elem;
    }
    MyWrapper.prototype.get = function() {
        return this.element;
    }

    var MyView = Backbone.View.extend({
        tagName : "div",
        id : "view",
        events : {
            "click #button" : "onButton",
        },    
        initialize : function(options) {        
            // done for demo purposes only, should be using templates
            this.html_text = "<input type='text' id='textbox' /><button id='button'>Remove</button>";        
            this.listenTo(this,"all",function(){console.log("Event: "+arguments[0]);});
        },
        render : function() {        
            this.$el.html(this.html_text);

            this.wrapper = new MyWrapper();
            this.wrapper.set(this.$("#textbox"));
            this.wrapper.get().val("placeholder");

            return this;
        },
        onButton : function() {
            // assume this gets .remove() called on subviews (if they existed)
            this.trigger("cleanup");
            this.remove();
        }
    });

    var view = new MyView();
    $("#content").append(view.render().el);
}

main();

不过，我不清楚如何使用谷歌Chrome的探查，以验证这是否是，实际上的情况。有一个极大的事情，出现在堆探查快照，我不知道如何反code有什么好/坏。我已经看到了它的教程到目前为止，要么只是告诉我使用快照分析器或者给我对整个事件探查器是如何工作的一个非常详细的宣言。是否有可能只使用分析器作为一种工具，或者我真的要了解整个事情是怎么设计的？

However, I am unclear how to use Google Chrome's profiler to verify that this is, in fact, the case. There are a gazillion things that show up on the heap profiler snapshot, and I have no idea how to decode what's good/bad. The tutorials I've seen on it so far either just tell me to "use the snapshot profiler" or give me a hugely detailed manifesto on how the entire profiler works. Is it possible to just use the profiler as a tool, or do I really have to understand how the whole thing was engineered?

编辑：教程这样的：

<一个href=\"https://docs.google.com/$p$psentation/d/1wUVmf78gG-ra5aOxvTfYdiLkdGaR9OhXRnOlIcEmu2s/pub?start=false&loop=false&delayms=3000#slide=id.g14717ff3_0_23\">Gmail内存泄漏固定

<一个href=\"http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools/\">Using DevTools

重新的一些更强的材料的presentative在那里，从我所看到的东西。然而，除了引入的 3快照技术的概念的，我觉得他们提供非常​​少的实际知识（像我这样的初学者）条款。在使用DevTools教程不通过一个真实的例子工作，所以对事物的模糊和一般概念上的描述并不过分热情。至于Gmail的例如：

Are representative of some of the stronger material out there, from what I've seen. However, beyond introducing the concept of the 3 Snapshot Technique, I find they offer very little in terms of practical knowledge (for a beginner like me). The 'Using DevTools' tutorial doesn't work through a real example, so its vague and general conceptual description of things aren't overly helpful. As for the 'Gmail' example:

所以，你发现泄漏。现在怎么办？的

So you found a leak. Now what?

  

• 在检查分析面板的下半部泄漏的对象的固定路径

• Examine the retaining path of leaked objects in the lower half of the Profiles panel

如果分配的网站不能很容易地推断出（即事件监听器）：

If the allocation site cannot be easily inferred (i.e. event listeners):

仪器通过JS控制台固定对象的构造函数，以节省分配堆栈跟踪

Instrument the constructor of the retaining object via the JS console to save the stack trace for allocations

使用封闭？启用相应的现有标志（即goog.events.Listener.ENABLE_MONITORING）来设置施工期间creationStack财产

Using Closure? Enable the appropriate existing flag (i.e. goog.events.Listener.ENABLE_MONITORING) to set the creationStack property during construction

我发现自己阅读的，而不是更少经过困惑。并再次，它只是告诉我的做的东西，不是的如何的做出来。从我的角度来看，所有的信息在那里是不是太模糊或只会意义的人谁已经了解的过程。

I find myself more confused after reading that, not less. And, again, it's just telling me to do things, not how to do them. From my perspective, all of the information out there is either too vague or would only make sense to someone who already understood the process.

其中的一些更具体的问题已在 @乔纳森Naguin的答案被提出下面。

Some of these more specific issues have been raised in @Jonathan Naguin's answer below.

推荐答案

一个良好的工作流程，查找内存泄漏是在三快照的技术，最早是由Loreena李和Gmail小组，以解决一些他们的记忆问题。这些步骤是，在一般情况：

A good workflow to find memory leaks is the three snapshot technique, first used by Loreena Lee and the Gmail team to solve some of their memory problems. The steps are, in general:

• 以一个堆快照。


• 做的东西。


• 再举一个堆快照。


• 重复同样的东西。


• 再举一个堆快照。

在快照3的摘要视图快照1和2之间分配
• 过滤对象。

有关你的榜样，我已经适应了code，以显示这个过程（你可以找到它这里）延迟创建的骨干视图，直到开始按钮的单击事件。现在：

For your example, I have adapted the code to show this process (you can find it here) delaying the creation of the Backbone View until the click event of the Start button. Now:

• 运行HTML（使用此地址的本地保存），并采取快照。


• 单击开始，以创建视图。


• 另一个快照。


• 单击删除。


• 另一个快照。

在快照3的摘要视图快照1和2之间分配
• 过滤对象。

• Run the HTML (saved locally of using this address) and take a snapshot.
• Click Start to create the view.
• Take another snapshot.
• Click remove.
• Take another snapshot.
• Filter objects allocated between Snapshots 1 and 2 in Snapshot 3's "Summary" view.

现在你已经准备好查找内存泄漏！

Now you are ready to find memory leaks!

您会发现几个不同颜色的节点。红色节点没有从Javascript直接引用他们，但还活着，因为他们是一个分离的DOM树的一部分。有可能是从Javascript引用（也许作为一个封闭或变量）树中的节点，但巧合的是preventing被垃圾收集整个DOM树。

You will notice nodes of a few different colors. Red nodes do not have direct references from Javascript to them, but are alive because they are part of a detached DOM tree. There may be a node in the tree referenced from Javascript (maybe as a closure or variable) but is coincidentally preventing the entire DOM tree from being garbage collected.

黄节点但是确实有从Javascript直接引用。寻找在同一个超然DOM树从你的Javascript找到引用黄色节点。应特性导致从DOM窗口到元件的一个链

Yellow nodes however do have direct references from Javascript. Look for yellow nodes in the same detached DOM tree to locate references from your Javascript. There should be a chain of properties leading from the DOM window to the element.

在您的特定你可以看到标记为红色HTML div元素。如果展开元素，你会看到一个由缓存功能的引用。

In your particular you can see a HTML Div element marked as red. If you expand the element you will see that is referenced by a "cache" function.

选择该行，并在控制台输入$ 0时，你就会看到实际的功能和位置：

Select the row and in your console type $0, you will see the actual function and location:

>$0
function cache( key, value ) {
        // Use (key + " ") to avoid collision with native prototype properties (see Issue #157)
        if ( keys.push( key += " " ) > Expr.cacheLength ) {
            // Only keep the most recent entries
            delete cache[ keys.shift() ];
        }
        return (cache[ key ] = value);
    }                                                     jquery-2.0.2.js:1166

这是你的元素被引用。 Unfortunally没有什么可以做，它是从一个jQuery的内部机制。但是，只是为了测试用途，请功能，改变方法：

This is where your element is being referenced. Unfortunally there is not much you can do, it is a internal mechanism from jQuery. But, just for testing purpose, go the function and change the method to:

function cache( key, value ) {
    return value;
}

现在，如果你重复这个过程，你将不会看到任何红点：）

Now if you repeat the process you will not see any red node :)

文件：

• Eliminating内存泄漏在Gmail中。


• Easing JavaScript的内存概要在Chrome中DevTools 。

• Eliminating memory leaks in Gmail.
• Easing JavaScript Memory Profiling In Chrome DevTools.

这篇关于查找JavaScript的内存泄漏铬的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！