JS中的内存泄漏

时间:2019-03-19 13:51:32

标签: javascript asp.net-mvc memory-leaks

我有一个包含以下内容的javascript文件。

"use strict";
$(function () {
var divs = $(".sc-frames");
var next = 0;
var currentIndex = 0;

var request = function (action, controller, div) {
    var url = "../" + controller + "/" + action;

    $.ajax({
        type: "GET",
        url: url,
        dataType: "html",
        async: false,
        timeout:10000,
        success: function (result) {

            writeResponse(result, div);
        },
        error: function () {
            $("#errorMessage").show();
        }
    });
};

var writeResponse = function (result, div) {
    $(div).hide().html(result).slideDown("slow"); 
    currentIndex = divs.index($(div));
    if (parseInt(divs.length - 1) == parseInt(currentIndex)) {
        next = 0;
    } else {
        next++;
    }
};

var createRequest = function () {
    $("#errorMessage").hide();
    $(divs[currentIndex]).empty(); 
    var div = divs[next]; 
    var action = $(div).attr("data-action");
    var controller = $(div).attr("data-controller");
    request(action, controller, div);
};

setInterval(createRequest, 30000);
createRequest(); 

});

这只是对3控制器操作方法进行了ajax调用,并将视图依次依次并连续地发布到divs。

但是当我在Google chrome开发工具中检查性能监视器时,它显示了js内存泄漏。 Js堆大小正在缓慢增加。

有没有办法找出内存泄漏的确切位置?

谢谢。

更新 enter image description here

3 个答案:

答案 0 :(得分:0)

The Js heap size is slowly increasing.

That's not (necessarily) a memory leak. It happens as most engines use stop-the-world garbage collection, which means, that variables will stay in memory although they might could get collected already, then at some point the GC kicks in, stops the currently executing JS, checks all the references and frees memory that is not referenced anymore, and then continues execution (it is done like this as JS is very dynamic, you can't tel wether a variable that leaves the scope is completely dereferenced, if you check all variables at once you know for sure).

However, that makes garbage collection a performance costly operation. Therefore the GC tries to kick in as rarely as possible, which means that it only kicks in, if memory is needed (as it is full).

Therefore you don't necessarily have a memory leak (and I don't see one in the code). Observe the heap over a longer period of time, and wait for a few gc cycles or trigger them manually (looks like a saw then), then check wether that overall graph is increasing. If it does, you got a memory leak, as there are elements that survive garbagge collection, they are leaking.

Is there a way to find out where exactly the memory leak is?

Using most debuggers you can create a "snapshot" of the current's memory state. Take two of them, one before and after garbage collection, then compare them to find out what exactly is leaked, then it is usually possible to trace that back to the code thats leaking it.

答案 1 :(得分:-1)

您需要使用clearInterval(createRequest);

不再需要运行代码时。

答案 2 :(得分:-1)

您可以通过删除一些小的功能(或单行)来找出何时不会发生这种情况-然后您知道是什么原因导致的。但是,我找不到停止循环的地方?也许这是每30秒发送一次请求,并且永不停止?