使用 jQuery remove() 会导致内存泄漏

发布于 2025-01-04 21:31:36 字数 964 浏览 0 评论 0原文

我有一个 div,我经常在其中创建子 div,然后删除它们。插入函数看起来像这样。

var insert = function(container, content) {
    content = $(content);
    container.append(content);
    return content;
};

var newContent = insert($('#container'), '<div>new content</div>');

// later
newContent.remove();

容器是一个 jQuery 对象。 content 是一个类似于

new content> 的字符串。随后,该新内容将被删除。

div 已从 dom 中正确删除,但使用 chrome 的分析功能,我可以看到内存不断增长。该配置文件显示了一个字符串列表,其中数千个是我删除的内容。跟踪它,我发现jquery有一个名为fragments的属性。

$.fragments 是一个映射,其中键字符串是 html 片段(字面意思是

new content
是键字符串),值是 DocumentFragment 对象。

DocumentFragment 对象包含一个属性“native”,该属性包含“Detached DOM 树”类型的值。还有我的独立物体。

问题似乎是 jQuery 没有刷新这个 $.fragments 集合。我正在使用 jQuery 1.7.1。

我看到的一个可能的原因是地图的键是插入的 html,但是当我开始删除片段时,我已经更改了 newContent div 的属性。

一种可能的解决方案是保留一组未使用的新内容 div 并重新使用它们。我真的不想这样做,但这可能是合理的。

I have a div in which I frequently create child divs and later remove them. The insert function looks like this.

var insert = function(container, content) {
    content = $(content);
    container.append(content);
    return content;
};

var newContent = insert($('#container'), '<div>new content</div>');

// later
newContent.remove();

container is a jQuery object. content is a string like <div>new content</div>. Later, that new content is removed.

The div is properly removed from the dom, but using chrome's profiling feature, I can see memory grow and grow. The profile shows a list of strings, thousands of which are my deleted content. Tracking it down, I see that jquery has a property called fragments.

$.fragments is a map where the key strings are html fragments (literally <div>new content</div> is the key string) and the values are DocumentFragment objects.

The DocumentFragment objects contain a property 'native' which contains a value of type 'Detached DOM tree'. And there is my detached object.

It seems like the problem is that jQuery is not flushing this $.fragments collection. I'm using jQuery 1.7.1.

One possible reason I could see for this is that the keys of the map are html that was inserted, but by the time I get around to deleting the fragment, I've changed the newContent div's attributes.

One possible solution is to keep a pool of unused new content divs and re-use them. I don't really want to do that, but it might be reasonable.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

九公里浅绿 2025-01-11 21:31:36

看起来 jQuery 确实使用 $.fragments 来加速 $("<...>")

我想使用 $("

").html(...) 不会使用缓存,但它在语义上显然是不同的。

您可以尝试偶尔自己刷新 $.fragments 并看看会发生什么。我有直觉,一切都会按预期进行,不会产生任何不良影响。

我不认为 jQuery 真的有办法跟踪片段缓存本身的使用情况,LRU 缓存或类似的东西可能会更慢,更不用说实现起来更麻烦了。

It does look like jQuery is using $.fragments to speed up $("<...>") then.

I suppose using $("<div>").html(...) would not use the cache, but it's obviously semantically different.

You could just try occasionally flushing $.fragments yourself and see what happens. I have the gut feeling everything would go just as expected with no ill effects.

I don't think jQuery really has a way to track the fragment cache usage itself, and an LRU cache or somesuch would probably be slower, not to mention more trouble implementing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文