1. V8内存管理和相关问题
Node.js基于V8引擎，其内存管理就是V8的内存管理。
V8内置了自动垃圾回收（GC）。
V8由Google开发，使用C++编写，最早在Chrome中使用。相对于其他JavaScript引擎将代码装换成字节码或解释执行，V8将代码变异成原生机器码，并且使用了如内联缓存等方法来提高性能。JavaScript程序在V8引擎下运行速度媲美二进制程序。
autoauto- 1. V8内存管理和相关问题 (原)auto - 1.1. V8内存设计auto - 1.1.1. 内存分区auto - 1.1.2. 内存生命周期auto - 1.2. V8垃圾回收auto - 1.2.1. 标记清除法auto - 1.2.2. 垃圾回收算法auto - 1.3. Node.js如何检视内存和GCauto - 1.3.1. 测试auto - 1.3.1.1. external内存和GC测试auto - 1.3.1.2. heap内存和GC测试auto - 1.3.2. 更多auto - 1.3.2.1. 总结auto - 1.4. 常见的内存泄漏案例auto - 1.4.1. 全局变量auto - 1.4.2. 闭包auto - 1.4.3. 消费者速度小于生产者auto - 1.5. 如何发现和定位内存问题auto - 1.5.1. memwatch-nextauto - 1.5.2. heapdumpauto - 1.5.3. 使用PM2做 Memory Threshold Auto Reload 处理autoauto
1.1. V8内存设计
1.1.1. 内存分区
V8中，内存分为几个部分：
新生代区 new space
大多数的对象都会被分配在这里，这个区域很小但是垃圾回收比较频繁。老生代区 old space
属于老生代，这里只保存原始数据对象，这些对象没有指向其他对象的指针。大对象区 large object space
这里存放体积超越其他区大小的对象，每个对象有自己的内存，垃圾回收其不会移动大对象区。代码区 code space
代码对象，会被分配在这里。唯一拥有执行权限的内存。map区 map space
存放 Cell 和 Map，每个区域都是存放相同大小的元素，结构简单。
1.1.2. 内存生命周期
一个对象A创建后，被分配到新生代区。
新生代区满后，V8进行Scavenge操作，清除需要回收的。如果对象A还有效，则保留。
如果对象A再次被清理（或者满足其他条件），则晋升到老生代区。
老生代区满后，V8进行Mark Sweep操作，将这时需要回收的对象A清除。
1.2. V8垃圾回收
1.2.1. 标记清除法
当变量进入环境（例如，在函数中声明一个变量）时，就将这个变量标记为“进入环境”。从逻辑上讲，永远不能释放进入环境的变量所占用的内存，因为只要执行流进入相应的环境，就可能会用到它们。而当变量离开环境时，则将其标记为“离开环境”。
与之对应的还有引用计数法，但会因循环引用导致内存泄漏，所以很少见到。
1.2.2. 垃圾回收算法
由于新生代和老生代存放了不同性质的内存对象，其清除方式也不同。
简单来说，新生代使用Scavenge算法。分成From和To两个区，将需要回收的对象留在From，其他移到To，然后交换From和To。垃圾回收将To空间内存全部释放。
老生代使用Mark Sweep算法，直接标记需要被回收的对象，在垃圾回收时释放相应地址空间。
此外，还有Mark Compact算法，将存活和需要回收的对象放在地址区域的两边，以避免回收后内存不连续的问题。
1.3. Node.js如何检视内存和GC
Node.js提供了一些API来帮助开发者检视程序的内存使用状况和GC情况。
process.memoryUsage()
会返回一个内存使用信息对象，单位为字节Byte。类似：
Object {rss: 25358336, heapTotal: 8232960, heapUsed: 5488248, external: 8608}
- rss 驻留集大小, 即程序分配的物理内存大小，包括堆、栈、代码段
- heapTotal V8堆总大小
- heapTotal V8堆使用量大小
- external V8绑定到Javascript的C++对象的内存大小
对象，字符串，闭包等存于堆内存。 变量存于栈内存。 实际的JavaScript源代码存于代码段内存。
1.3.1. 测试
下面的测试，执行时都给node添加启动参数--trace-gc和--expose-gc。
前者可以打印出GC操作log，后者允许在代码中控制GC。
1.3.1.1. external内存和GC测试
尝试用fs.readFileSync('/path/')读取一个100M左右的文件。发现rss和external增加了100M左右。
heapUsed则只增加了一点。看来直接读取文件返回的是一个C++对象的引用。
即使没有保存fs.readFileSync()返回的对象，rss和external还是增大了。且即使等待，这部分内存也不会被回收。
在代码中调用global.gc()主动进行GC回收。
回收后，增加的100M左右rss被释放。
1.3.1.2. heap内存和GC测试
如果使用fs.readFileSync('/path/', 'utf-8')，返回的将是一个字符串对象。会占用heap内存。
反复执行10次并保留每次的引用，发现程序错误：
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
这体现了V8的堆内存大小是有限制的。这个限制可以修改。
老生代用node --max-old-space-size=xxxx（单位MB）修改。
新生代用node --max-new-space-size=xxxx（单位MB）修改。
1.3.2. 更多
-
node --v8-optionsprint v8 command line options -
node --v8-pool-size=numset v8's thread pool size -
node --prof-processprocess v8 profiler output generated using --prof -
node --track-heap-objectstrack heap object allocations for heap snapshots -
os.totalmem()系统总内存 -
os.freemem()系统空闲内存
1.3.2.1. 总结
通过测试，可以发现GC的一些表面规则：
- 部分函数会创建C++对象并返回其引用，而不是JS对象。因此占用external而非heap。
- global.x 不会被回收。const x，如果后面没有使用x，则会很快被回收。
1.4. 常见的内存泄漏案例
1.4.1. 全局变量
全局变量global.xxx不会被GC回收。
未声明变量会隐式产生全局变量：
function foo() {
// 即 global.a = 1;
a = 1;
}
使用tslint等工具规范代码可以避免此种问题。
1.4.2. 闭包
闭包就是能够读取其他函数内部变量的函数。
闭包作用域会保留其中涉及的引用，会导致对象无法被回收。
要注意的一个知识点是：每当在同一个父作用域下创建闭包作用域的时候，这个作用域是被共享的。
看一个经典问题（曾经是web框架meteor的著名bug）：
let theThing = null;
const replaceThing = function () {
const originalThing = theThing;
function unused() {
if (originalThing) {}
}
theThing = {
longStr: new Array(1000000).join('*'),
someMethod: () => {}
};
};
setInterval(() => {
replaceThing();
console.log(process.memoryUsage().heapTotal)
}, 1000);
运行这段代码，会发现rss、heapTotal、heapUsed不断增长。
这是因为在replaceThing()的词法作用域中，声明了originalThing，而闭包函数unused()使用了originalThing；theThing.someMethod()虽然是空函数，但由于上面提及的知识点，其闭包作用域也包含了originalThing，而theThing定义在文件作用域，无法回收。
这些就导致了每次重声明的originalThing都无法回收，就会有大量longStr积累在堆中。
如果需要解决这个问题，可以在replaceThing()的最后加originalThing = null;。
这个问题出现的关键在于，变量间产生了循环使用，且一个在闭包作用域中，导致其每次定义后，都无法释放。
也可以改成下面这样，效果一样：
let theThing = null;
const replaceThing = function () {
const originalThing = {
theThing,
longStr: new Array(1000000).join('*'),
};
function unused() {
if (originalThing) {}
}
theThing = ()=> {}
};
setInterval(() => {
replaceThing();
console.log(process.memoryUsage().heapTotal)
}, 1000);
1.4.3. 消费者速度小于生产者
常见于使用消息队列或大量IO操作时。由于作为生产者时，消费者一方不能及时处理任务，导致任务数据在生产者内存缓存中大量积存，最终导致内存溢出。
1.5. 如何发现和定位内存问题
1.5.1. memwatch-next
memwatch-next是一个能发现内存泄漏问题，并给出简单问题分析的工具。
使用如下：
// 使用方式1：监听内存泄漏
// 5个连续GC周期下，
memwatch.on('leak', function (info) {
console.warn("MEMLEAK", info);
});
// 使用方式2：生成一段时间的内存和对象变化报告
const hd = new memwatch.HeapDiff();
setTimeout(() => {
const diff = hd.end();
console.log(JSON.stringify(diff, null, " "));
}, 1000 * 10);
在上面那个闭包引起内存泄漏的代码中使用，可以发现部分报告输出如下：
{
"change": {
"details": [
{
"what": "Closure",
"size_bytes": 6624,
"size": "6.47 kb",
"+": 96,
"-": 4
},
{
"what": "String",
"size_bytes": 93003520,
"size": "88.7 mb",
"+": 205,
"-": 22
}
]
}
}
由此，可以推测是大量String对象造成内存占用，可能和闭包有关。
1.5.2. heapdump
heapdump是一个用于导出V8 Heap Snapshot的工具。导出数据可以导入到Chrome浏览器查看。
和memwatch结合使用：
memwatch.on('leak', function (info) {
console.warn("MEMLEAK", info);
heapdump.writeSnapshot('' + Date.now() + '.heapsnapshot');
});
等到leak事件触发后，便会导出一个.heapsnapshot文件。从 [Chrome开发者工具]-[memory]-[Profiles]-[Heap snapshot] 中，Load这个文件。
然后就可以看到报告内容。
可以按Shallow Size排序，查看是何种对象占用了大量内存。（如果内存泄漏时缓慢增长的，则可以等待足够长时间后再导出报告）
对上面的闭包例子做报告，可以发现占用最多的是string，有多个大体积的“***...*”字符串。
1.5.3. 使用PM2做 Memory Threshold Auto Reload 处理
有时内存泄漏的问题隐藏地很深，短时间内难以定位和解决。这时要优先保证服务正常运行不收内存
问题的影响，就可以利用pm2管理工具的内存限制重启特性。
具体方式是在配置文件中增加max_memory_restart属性：
apps: [{
max_memory_restart: '300M'
}]
