js中如果不用var声明变量,该变量将被视为window对象(全局对象)的属性,也就是全局变量.
function foo(arg) {
bar = "this is a hidden global variable"
}123
// 上面的函数等价于
function foo(arg) {
window.bar = "this is an explicit global variable"
}123
所以,你调用完了函数以后,变量仍然存在,导致泄漏.
如果不注意this的话,还可能会这么漏:
function foo() {
this.variable = "potential accidental global"
}123
// 没有对象调用foo, 也没有给它绑定this, 所以this是window
foo()
你可以通过加上’use strict’启用严格模式来避免这类问题, 严格模式会组织你创建意外的全局变量.
被遗忘的定时器或者回调
var someResource = getData()
setInterval(function() {
var node = document.getElementById('Node') if(node) {
node.innerHTML = JSON.stringify(someResource))
}
}, 1000)1234567
这样的代码很常见, 如果id为Node的元素从DOM中移除, 该定时器仍会存在, 同时, 因为回调函数中包含对someResource的引用, 定时器外面的someResource也不会被释放.
没有清理的DOM元素引用
var elements = {button: document.getElementById('button'),image: document.getElementById('image'),text: document.getElementById('text')
}function doStuff() {
image.src = 'http://some.url/image'
button.click() console.log(text.innerHTML)
}function removeButton() {document.body.removeChild(document.getElementById('button')) // 虽然我们用removeChild移除了button, 但是还在elements对象里保存着#button的引用
// 换言之, DOM元素还在内存里面.
}123456789101112131415161718
闭包
先看这样一段代码:
var theThing = nullvar replaceThing = function () {
var someMessage = '123'
theThing = {
someMethod: function () {
console.log(someMessage)
}
}
}123456789
调用replaceThing之后, 调用theThing.someMethod, 会输出123, 基本的闭包, 我想到这里应该不难理解.
解释一下的话, theThing包含一个someMethod方法, 该方法引用了函数中的someMessage变量, 所以函数中的someMessage变量不会被回收, 调用someMethod可以拿到它正确的console.log出来.
接下来我这么改一下:
var theThing = nullvar replaceThing = function () {
var originalThing = theThing var someMessage = '123'
theThing = {
longStr: new Array(1000000).join('*'),// 大概占用1MB内存
someMethod: function () {
console.log(someMessage)
}
}
}1234567891011
我们先做一个假设, 如果函数中所有的私有变量, 不管someMethod用不用, 都被放进闭包的话, 那么会发生什么呢.
第一次调用replaceThing, 闭包中包含originalThing = null和someMessage = ‘123’, 我们设函数结束时, theThing的值为theThing_1.
第二次调用replaceThing, 如果我们的假设成立, originalThing = theThing_1和someMessage = ‘123’.我们设第二次调用函数结束时, theThing的值为theThing_2.注意, 此时的originalThing保存着theThing_1, theThing_1包含着和theThing_2截然不同的someMethod, theThing_1的someMethod中包含一个someMessage, 同样如果我们的假设成立, 第一次的originalThing = null应该也在.
所以, 如果我们的假设成立, 第二次调用以后, 内存中有theThing_1和theThing_2, 因为他们都是靠longStr把占用内存撑起来, 所以第二次调用以后, 内存消耗比第一次多1MB.
如果你亲自试了(使用Chrome的Profiles查看每次调用后的内存快照), 会发现我们的假设是不成立的, 浏览器很聪明, 它只会把someMethod用到的变量保存下来, 用不到的就不保存了, 这为我们节省了内存.
但如果我们这么写:
var theThing = nullvar replaceThing = function () {
var originalThing = theThing var unused = function () {
if (originalThing)
console.log("hi")
} var someMessage = '123'
theThing = {
longStr: new Array(1000000).join('*'),
someMethod: function () {
console.log(someMessage)
}
}
}123456789101112131415
unused 这个函数我们没有用到, 但是它用了 originalThing 变量, 接下来, 如果你一次次调用 replaceThing , 你会看到内存1MB 1MB的涨.
也就是说, 虽然我们没有使用 unused , 但是因为它使用了 originalThing , 使得它也被放进闭包了, 内存漏了.
强烈建议读者亲自试试在这几种情况下产生的内存变化.
这种情况产生的原因, 通俗讲, 是因为无论 someMethod 还是 unused , 他们其中所需要用到的在 replaceThing 中定义的变量是保存在一起的, 所以就漏了.
1、非静态内部类创建静态实例造成的内存泄漏。解决方法：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
2、Handler造成的内存泄漏，解决方法：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
3、线程造成的内存泄漏，解决方法：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
4、使用ListView时造成的内存泄漏，解决方法：在构造Adapter时，使用缓存的convertView。
5、集合容器中的内存泄露，解决方法：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
以上内容参考 百度百科-内存泄漏
内存泄漏的几种情况
一、全局变量
a = 10//未声明对象。global.b = 11//全局变量引用
这种比较简单的原因，全局变量直接挂在 root 对象上，不会被清除掉。
二、闭包
function out() {
const bigData = new Buffer(100)
inner = function () {
void bigData
}}
闭包会引用到父级函数中的变量，如果闭包未释放，就会导致内存泄漏。上面例子是 inner 直接挂在了 root 上，那么每次执行 out 函数所产生的 bigData 都不会释放，从而导致内存泄漏。
需要注意的是，这里举得例子只是简单的将引用挂在全局对象上，实际的业务情况可能是挂在某个可以从 root 追溯到的对象上导致的。
三、事件监听
Node.js 的事件监听也可能出现的内存泄漏。例如对同一个事件重复监听，忘记移除（removeListener），将造成内存泄漏。这种情况很容易在复用对象上添加事件时出现，所以事件重复监听可能收到如下警告：
(node:2752) Warning: Possible EventEmitter memory leak detected。11 haha listeners added。Use emitter。setMaxListeners() to increase limit
例如，Node.js 中 Agent 的 keepAlive 为 true 时，可能造成的内存泄漏。当 Agent keepAlive 为 true 的时候，将会复用之前使用过的 socket，如果在 socket 上添加事件监听，忘记清除的话，因为 socket 的复用，将导致事件重复监听从而产生内存泄漏。
原理上与前一个添加事件监听的时候忘了清除是一样的。在使用 Node.js 的 http 模块时，不通过 keepAlive 复用是没有问题的，复用了以后就会可能产生内存泄漏。所以，你需要了解添加事件监听的对象的生命周期，并注意自行移除。
关于这个问题的实例，可以看 Github 上的 issues（node Agent keepAlive 内存泄漏）
四、其他原因
还有一些其他的情况可能会导致内存泄漏，比如缓存。在使用缓存的时候，得清楚缓存的对象的多少，如果缓存对象非常多，得做限制最大缓存数量处理。还有就是非常占用 CPU 的代码也会导致内存泄漏，服务器在运行的时候，如果有高 CPU 的同步代码，因为Node.js 是单线程的，所以不能处理处理请求，请求堆积导致内存占用过高。
定位内存泄漏
一、重现内存泄漏情况
想要定位内存泄漏，通常会有两种情况：
对于只要正常使用就可以重现的内存泄漏，这是很简单的情况只要在测试环境模拟就可以排查了。
对于偶然的内存泄漏，一般会与特殊的输入有关系。想稳定重现这种输入是很耗时的过程。如果不能通过代码的日志定位到这个特殊的输入，那么推荐去生产环境打印内存快照了。需要注意的是，打印内存快照是很耗 CPU 的操作，可能会对线上业务造成影响。
快照工具推荐使用 heapdump 用来保存内存快照，使用 devtool 来查看内存快照。使用 heapdump 保存内存快照时，只会有 Node.js 环境中的对象，不会受到干扰（如果使用 node-inspector 的话，快照中会有前端的变量干扰）。
PS：安装 heapdump 在某些 Node.js 版本上可能出错，建议使用 npm install heapdump -target=Node.js 版本来安装。
二、打印内存快照
将 heapdump 引入代码中，使用 heapdump.writeSnapshot 就可以打印内存快照了了。为了减少正常变量的干扰，可以在打印内存快照之前会调用主动释放内存的 gc() 函数（启动时加上 --expose-gc 参数即可开启）。
const heapdump = require('heapdump')const save = function () {gc()
heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot')}
在打印线上的代码的时候，建议按照内存增长情况来打印快照。heapdump 可以使用 kill 向程序发送信号来打印内存快照（只在 *nix 系统上提供）。
kill -USR2 <pid>推荐打印 3 个内存快照，一个是内存泄漏之前的内存快照，一个是少量测试以后的内存快照，还有一个是多次测试以后的内存快照。
第一个内存快照作为对比，来查看在测试后有哪些对象增长。在内存泄漏不明显的情况下，可以与大量测试以后的内存快照对比，这样能更容易定位。
三、对比内存快照找出泄漏位置
通过内存快照找到数量不断增加的对象，找到增加对象是被谁给引用，找到问题代码，改正之后就行，具体问题具体分析，这里通过我们在工作中遇到的情况来讲解。
const {EventEmitter} = require('events')const heapdump = require('heapdump')global.test = new EventEmitter()heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot')function run3() {const innerData = new Buffer(100)
const outClosure3 = function () {
void innerData
}
test.on('error', () =>{
console.log('error')
})
outClosure3()}for(let i = 0i <10i++) {
run3()}gc()heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot')
这里是对错误代码的最小重现代码。
首先使用 node --expose-gc index.js 运行代码，将会得到两个内存快照，之后打开 devtool，点击 profile，载入内存快照。打开对比，Delta 会显示对象的变化情况，如果对象 Delta 一直增长，就很有可能是内存泄漏了。
