使用 jQuery remove() 会导致内存泄漏
我有一个 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 片段(字面意思是
是键字符串),值是 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
看起来 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.