js内存泄露学习(转)

http://blog.csdn.net/kaitiren/article/details/19974269内存泄露不错的帖子,感谢分享

Google Chrome浏览器提供了非常强大的JS调试工具,Heap Profiling便是其中一个。Heap Profiling可以记录当前的堆内存(heap)快照,并生成对象的描述文件,该描述文件给出了当时JS运行所用到的所有对象,以及这些对 ...

一、概述

Google Chrome浏览器提供了非常强大的JS调试工具,Heap Profiling便是其中一个。Heap Profiling可以记录当前的堆内存(heap)快照,并生成对象的描述文件,该描述文件给出了当时JS运行所用到的所有对象,以及这些对象所占用的内存大小、引用的层级关系等等。这些描述文件为内存泄漏的排查提供了非常有用的信息。

注意:本文里的所有例子均基于Google Chrome浏览器。

什么是heap

JS运行的时候,会有栈内存(stack)和堆内存(heap),当我们用new实例化一个类的时候,这个new出来的对象就保存在heap里面,而这个对象的引用则存储在stack里。程序通过stack里的引用找到这个对象。例如var a = [1,2,3];,a是存储在stack里的引用,heap里存储着内容为[1,2,3]的Array对象。

二、Heap Profiling

打开工具

打开Chrome浏览器(版本25.0.1364.152 m),打开要监视的网站(这里以游戏大厅为例),按下F12调出调试工具,点击“Profiles”标签。可以看到下图:

可以看到,该面板可以监控CPU、CSS和内存,选中“Take Heap Snapshot”,点击“Start”按钮,就可以拍下当前JS的heap快照,如下图所示:

右边视图列出了heap里的对象列表。由于游戏大厅使用了Quark游戏库,所以这里可以清楚地看到Quark.XXX之类的类名称(即Function对象的引用名称)。

注意:每次拍快照前,都会先自动执行一次GC,所以在视图里的对象都是可及的。

视图解释

列字段解释:

Constructor -- 类名Distance -- 估计是对象到根的引用层级距离

Objects Count -- 给出了当前有多少个该类的对象

Shallow Size -- 对象所占内存(不包含内部引用的其它对象所占的内存)(单位:字节)

Retained Size -- 对象所占总内存(包含内部引用的其它对象所占的内存)(单位:字节)

下面解释一下部分类名称所代表的意思:

(compiled code) -- 未知,估计是程序代码区

(closure) -- 闭包(array) -- 未知

Object -- JS对象类型(system) -- 未知

(string) -- 字符串类型,有时对象里添加了新属性,属性的名称也会出现在这里

Array -- JS数组类型cls -- 游戏大厅特有的继承类

Window -- JS的window对象

Quark.DisplayObjectContainer -- Quark引擎的显示容器类

Quark.ImageContainer -- Quark引擎的图片类

Quark.Text -- Quark引擎的文本类

Quark.ToggleButton -- Quark引擎的开关按钮类

对于cls这个类名,是由于游戏大厅的继承机制里会使用“cls”这个引用名称,指向新建的继承类,所以凡是使用了该继承机制的类实例化出来的对象,都放在这里。例如程序中有一个类ClassA,继承了Quark.Text,则new出来的对象是放在cls里,不是放在Quark.Text里。

查看对象内容

点击类名左边的三角形,可以看到所有该类的对象。对象后面的“@70035”表示的是该对象的ID(有人会错认为是内存地址,GC执行后,内存地址是会变的,但对象ID不会)。把鼠标停留在某一个对象上,会显示出该对象的内部属性和当时的值。

这个视图有助于我们辨别这是哪个对象。但该视图跟踪不了是被谁引用了。

查看对象的引用关系

点击其中一个对象,能看到对象的引用层级关系,如下图:

Object‘s retaining tree视图显示出了该对象被哪些对象引用了,以及这个引用的名称。图中的这个对象被5个对象引用了,分别是:

1. 一个cls对象的_txtContent变量;

2. 一个闭包函数的context变量;

3. 同一个闭包函数的self变量;

4. 一个数组对象的0位置;

5. 一个Quark.Tween对象的target变量。

看到context和self这两个引用,可以知道这个Quark.Text对象使用了JS常用的上下文绑定机制,被一个闭包里的变量引用着,相当于该Quark.Text对象多了两个引用,这种情况比较容易出现内存泄漏,如果闭包函数不释放,这个Quark.Text对象也释放不了。

展开_textContent,可以看到下一级的引用:

把这个树状图反过来看,可以看到,该对象(ID @70035)其中的一条引用链是这样的:

GameListV       _curV       _gameListV    省略...

\         |        /

\       |       /

_noticeWidget

|

_noticeC

|

_noticeV

|

_txtContent

||

Quark.Text @70035

内存快照的对比通过快照对比的功能,可以知道程序在运行期间哪些对象变更了。

刚才已经拍下了一个快照,接下来再拍一次,如下图:

点击图中的黑色实心圆圈按钮,即可得到第二个内存快照:

然后点击图中的“Snapshot 2”,视图才会切换到第二次拍的快照。

点击图中的“Summary”,可弹出一个列表,选择“Comparison”选项,结果如下图:

这个视图列出了当前视图与上一个视图的对象差异。列名字段解释:# New -- 新建了多少个对象# Deleted -- 回收了多少个对象# Delta -- 对象变化值,即新建的对象个数减去回收了的对象个数Size Delta -- 变化的内存大小(字节)注意Delta字段,尤其是值大于0的对象。下面以Quark.Tween为例子,展开该对象,可看到如下图所示:

在“# New”列里,如果有“.”,则表示是新建的对象。

在“# Deleted”列里,如果有“.”,则表示是回收了的对象。

平时排查问题的时候,应该多拍几次快照进行对比,这样有利于找出其中的规律。

三、内存泄漏的排查

JS程序的内存溢出后,会使某一段函数体永远失效(取决于当时的JS代码运行到哪一个函数),通常表现为程序突然卡死或程序出现异常。

这时我们就要对该JS程序进行内存泄漏的排查,找出哪些对象所占用的内存没有释放。这些对象通常都是开发者以为释放掉了,但事实上仍被某个闭包引用着,或者放在某个数组里面。

观察者模式引起的内存泄漏

有时我们需要在程序中加入观察者模式(Observer)来解藕一些模块,但如果使用不当,也会带来内存泄漏的问题。

排查这类型的内存泄漏问题,主要重点关注被引用的对象类型是闭包(closure)和数组Array的对象。

下面以德州扑克游戏为例:

测试人员发现德州扑克游戏存在内存溢出的问题,重现步骤:进入游戏--退出到分区--再进入游戏--再退出到分区,如此反复几次便出现游戏卡死的问题。

排查的步骤如下:

1.打开游戏;

2.进入第一个分区(快速场5/10);

3.进入后,拍下内存快照;

4.退出到刚才的分区界面;

5.再次进入同一个分区;

6.进入后,再次拍下内存快照;

7.重复步骤2到6,直到拍下5组内存快照;

8.将每组的视图都转换到Comparison对比视图;

9.进行内存对比分析。

经过上面的步骤后,可以得到下图结果:

先看最后一个快照,可以看到闭包(closure)+1,这是需要重点关注的部分。(string)、(system)和(compiled code)类型可以不管,因为提供的信息不多。

接着点击倒数第二个快照,看到闭包(closure)类型也是+1。

接着再看上一个快照,闭包还是+1。

这说明每次进入游戏都会创建这个闭包函数,并且退出到分区的时候没有销毁。

展开(closure),可以看到非常多的function对象:

建新的闭包数量是49个,回收的闭包数量是48个,即是说这次操作有48个闭包正确释放了,有一个忘记释放了。每个新建和回收的function对象的ID都不一样,找不到任何的关联性,无法定位是哪一个闭包函数出了问题。

接下来打开Object‘s retaining tree视图,查找引用里是否存在不断增大的数组。

如下图,展开“Snapshot 5”每个function对象的引用:

其中有个function对象的引用deleFunc存放在一个数组里,下标是4,数组的对象ID是@45599。

继续查找“Snapshot 4”的function对象:

发现这里有一个function的引用名称也是deleFunc,也存放在ID为@45599的数组里,下标是3。这个对象极有可能是没有释放掉的闭包。

继续查看“Snapshot 3”里的function对象:

从图中可以看到同一个function对象,下标是2。那么这里一定存在内存泄漏问题。

数组下面有一个引用名称“login_success”,在程序里搜索一下该关键字,终于定位到有问题的代码。因为进入游戏的时候注册了“login_success”通知:

ob.addListener("login_success", _onLoginSuc);

但退出到分区的时候,没有移除该通知,下次进入游戏的时候,又再注册了一次,所以造成function不断增加。改成退出到分区的时候移除该通知:

ob.removeListener("login_success", _onLoginSuc);

这样就成功解决这个内存泄漏的问题了。

德州扑克这种问题多数见于观察者设计模式中,使用一个全局数组存储所有注册的通知,如果忘记移除通知,则该数组会不断增大,最终造成内存溢出。

上下文绑定引起的内存泄漏

很多时候我们会用到上下文绑定函数bind(也有些人写成delegate),无论是自己实现的bind方法还是JS原生的bind方法,都会有内存泄漏的隐患。

下面举一个简单的例子:        
<script type="text/javascript">
                var ClassA = function(name){
                        this.name = name;
                        this.func = null;
                };

var a = new ClassA("a");
                var b = new ClassA("b");

b.func = bind(function(){
                        console.log("I am " + this.name);
                }, a);

b.func();  //输出 I am a

a = null;        //释放a
                //b = null;        //释放b

//模拟上下文绑定
                function bind(func, self){
                        return function(){
                                return func.apply(self);
                        };
                }; 
</script>
上面的代码中,bind通过闭包来保存上下文self,使得事件b.func里的this指向的是a,而不是b。
首先我们把b = null;注释掉,只释放a。看一下内存快照:

可以看到有两个ClassA对象,这与我们的本意不相符,我们释放了a,应该只存在一个ClassA对象b才对。

从上面两个图可以看出这两个对象中,一个是b,另一个并不是a,因为a这个引用已经置空了。第二个ClassA对象是bind里的闭包的上下文self,self与a引用同一个对象。虽然a释放了,但由于b没有释放,或者b.func没有释放,使得闭包里的self也一直存在。要释放self,可以执行b=null或者b.func=null。

把代码改成:

<script type="text/javascript">

var ClassA = function(name){

this.name = name;

this.func = null;

};

var a = new ClassA("a");

var b = new ClassA("b");

b.func = bind(function(){

console.log("I am " + this.name);

}, a);

b.func();        //输出 I am a

a = null;        //释放a

b.func = null;        //释放self

//模拟上下文绑定

function bind(func, self){

return function(){

return func.apply(self);

};

};

</script>

再看看内存:

可以看到只剩下一个ClassA对象b了,a已被释放掉了。

四、结语

JS的灵活性既是优点也是缺点,平时写代码时要注意内存泄漏的问题。当代码量非常庞大的时候,就不能仅靠复查代码来排查问题,必须要有一些监控对比工具来协助排查。

之前排查内存泄漏问题的时候,总结出以下几种常见的情况:

1.闭包上下文绑定后没有释放;

2.观察者模式在添加通知后,没有及时清理掉;

3.定时器的处理函数没有及时释放,没有调用clearInterval方法;

4.视图层有些控件重复添加,没有移除。

js内存泄露学习(转)

时间: 2024-10-17 19:12:42

js内存泄露学习(转)的相关文章

java 内存泄露 学习

1.什么事内存泄露 内存泄露就是对象不用了,但是无法回收该对象占用的内存. 2.java不是有垃圾回收机制,咋还会发生内存泄露呢? java的垃圾回收机制就是把无用的对象(GC roots可达与否)用的内存回收,但是垃圾回收不是万能的,在一些场合会出现内存泄露, 长对象持有短对象的引用, 1.静态集合类 1 Static Vector v = new Vector(10); 2 for (int i = 1; i<100; i++) 3 { 4 Object o = new Object();

node.js内存泄露问题记录

先说一下.事情的来龙去脉. 公司开发一款游戏棋牌游戏,服务端的开发是IO密集型,开发的时候,考虑过使用python,java,node.js. 终于选择了node.js(node.js宣传的杀手功能.异步IO,node.js另外一个分支叫io.js),事情也就由此而起. 由于第一次做手机游戏.对移动网络的预计不足.选择了json作为通信数据传输格式.上线后玩家就频繁掉线(通信数据量太大,移动网络hold不住), 于是想了一个解决方式,把json数据用zip压缩一下,事情好像就万事大吉了(尽管也有

js内存泄露的几种情况

想解决内存泄露问题,必须知道什么是内存泄露,什么情况下出现内存泄露,才能在遇到问题时,逐个排除.这里只讨论那些不经意间的内存泄露. 一.什么是内存泄露 内存泄露是指一块被分配的内存既不能使用,又不能回收,直到浏览器进程结束.在C++中,因为是手动管理内存,内存泄露是经常出现的事情.而现在流行的C#和Java等语言采用了自动垃圾回收方法管理内存,正常使用的情况下几乎不会发生内存泄露.浏览器中也是采用自动垃圾回收方法管理内存,但由于浏览器垃圾回收方法有bug,会产生内存泄露. 二.内存泄露的几种情况

[转载] js内存泄露的几种情况——javascript系列

想解决内存泄露问题,必须知道什么是内存泄露,什么情况下出现内存泄露,才能在遇到问题时,逐个排除.这里只讨论那些不经意间的内存泄露. 一.什么是内存泄露 内存泄露是指一块被分配的内存既不能使用,又不能回收,直到浏览器进程结束.在C++中,因为是手动管理内存,内存泄露是经常出现的事情.而现在流行的C#和Java等语言采用了自动垃圾回收方法管理内存,正常使用的情况下几乎不会发生内存泄露.浏览器中也是采用自动垃圾回收方法管理内存,但由于浏览器垃圾回收方法有bug,会产生内存泄露. 二.内存泄露的几种情况

一个JS内存泄露实例分析

在看JS GC 相关的文章时,好几次看到了下面这个设计出来的例子,比较巧妙,环环相扣. var theThing = null; var replaceThing = function () { var originalThing = theThing; var unused = function () { if (originalThing) console.log("hi"); }; theThing = { longStr: new Array(10000).join('*'),

Node.js 内存泄露 定位

之前我们在64位Linux服务器上使用Node.js时,当Node进程物理内存接近1.6G,由于谷歌V8引擎对内存的限制,会导致进程退出! 显然我们自身编码或npm加载的第3行模块存在内存泄露问题,那么如何去定位呢? 常见的调试工具: v8-profiler node-heapdump node-mtrace dtrace node-memwatch 具体定位的方法可参考: https://hacks.mozilla.org/2012/11/tracking-down-memory-leaks-

js内存泄露的几种情况详细探讨

内存泄露是指一块被分配的内存既不能使用,又不能回收,直到浏览器进程结束,由于浏览器垃圾回收方法有bug,会产生内存泄露,下面与大家详细探讨下内存泄露的几种情况 内存泄露是指一块被分配的内存既不能使用,又不能回收,直到浏览器进程结束.在C++中,因为是手动管理内存,内存泄露是经常出现的事情.而现在流行的 C#和Java等语言采用了自动垃圾回收方法管理内存,正常使用的情况下几乎不会发生内存泄露.浏览器中也是采用自动垃圾回收方法管理内存,但由于浏览器 垃圾回收方法有bug,会产生内存泄露. 1.当页面

js内存泄露的原因

1.意外的全局变量 function fun(){ a=19//全局变量 console.log(a) } 2.未及时清理计时器或者回调函数 //记得及时清理定时器 var intervalId=setInterval(function () { console.log("demo") },100); clearInterval(intervalId); 3.闭包数据 //闭包 function fn() { var a=10 function fn2() { console.log(

JavaScript垃圾回收(三)——内存泄露

一.JavaScript内存监测工具 在讨论内存泄露之前,先介绍几款JavaScript内存监测工具. IE的sIEve与JSLeaksDetector(这两个可以在下面的附件中下载),firefox的Leak Monitor,chrome的Porfiles等. 1.Leak Monitor好不容易找到下载链接,但是我的firefox的版本安装不了. 2.chrome的Porfiles,点击F12就能看到,如下图所示: 3.IE的JSLeaksDetector,我用的是win7系统,后面发现64