↑残局一张图，故事端赖编↑
从一次宕机提及
这是一个很狗血的故事，故事的开首是一个项目，这个项目非常轻率，轻率到什么程度？没有设想稿，没有文档，需求端赖口口相传，固然最轻率的是交给了我，我简朴列了下需求：
- 官网的情势，重要引见公司某些营业
- 要能发文章
只管很简朴的需求，关于水得一匹的我来讲，简直是“难于上青天”，三大件(html,css,javascript)我样样精通个P，网站布置我也只略知一二，代码编程度更是不学无术。作为Copy工程师，碰到需求我便最先了copy之路，先github散步了一圈，找了几个满足需求的项目，终究对比了一下，挑选了一个名叫iBlog2的项目–基于 Node.js 的个人开源博客体系。您没看错，就是一个博客体系！这跟官网有个毛关联？这个宕机又有个毛关联？我想说的是，经由copy然后小改以后，iBlog2摇身一变就成了能宣布文章的官网项目，就是这么简朴粗犷，就是这么不学无术(温馨提醒：少壮不努力，老大偷代码)。
这个3年之前的项目，在现在看来的确是有些陈腐，但作者@eshengsky照旧锲而不舍的在更新保护,而关于我而言，只是为了完成能发文章的官网，所以只关注文章是怎样宣布和贮存的，恰好是因为我关注的面窄，疏忽了布置和布置以后能够会碰到的种种题目，比方window下pm2能够涌现题目、比方此次的JavaScript heap out of memory。固然并非人家开源项目有题目，而是现实布置的时刻压根没根据作者的文档来，假如根据文档，我应该用pm2布置，或许启用redis，或许运用Noginx,或许运用本机的MongoDB效劳，但是，这一切，我只是在我们谁人效劳器新开了个端口，然后直接npm run dev就最先跑在线上了，所以呢，这么“锈”的操纵，不宕机才是天理难容，印象中JavaScript heap out of memory碰到两次了，才两三个月啊！
检索JavaScript heap out of memory
平常碰到题目，我首选的处理流程是翻开Chrome–输入症结词–搜刮–浏览–copy–尝试，彷佛从来没有去思索过发生题目的泉源，以至都没有去纪录这个题目以及处理的计划，致使再碰到一样的坑，又掉进去了，然后又是一通检索尝试等操纵，这也是我从业这么多年来，一向没养成的习气，也是这么多年一向没生长的某一个小的缘由，“少埋怨，多思索，将来会更优美”，而我一向以反面教材在解释这个金句。
平常来讲，只需您的症结词够正确，您就能够经由过程google搜刮找到尽量惬意的处理计划，假如连症结词都没把握好，我想就算讨教的大牛，也不一定能有用的回复，固然思否和Stack Overflow都能够有填您谁人坑的“铁楸”，另有一个阵地就是github。
平常来讲，顺序报错平常都有细致的报错申明，比方哪一行、出了什么错、失足明细等，就比方文章开首的那张报错图，我找到了其他用户碰到的如出一辙的题目：
<--- Last few GCs --->
[8138:0x102801600] 145460 ms: Mark-sweep 1265.6 (1301.6) -> 1265.6 (1308.6) MB, 289.8 / 0.0 ms allocation failure GC in old space requested
[8138:0x102801600] 145740 ms: Mark-sweep 1265.6 (1308.6) -> 1265.6 (1277.6) MB, 280.6 / 0.0 ms last resort gc
[8138:0x102801600] 146035 ms: Mark-sweep 1265.6 (1277.6) -> 1265.6 (1277.6) MB, 295.0 / 0.0 ms last resort gc
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x39c891dc0d31 <JS Object>
1: DoJoin(aka DoJoin) [native array.js:~97] [pc=0x5d1facabad4](this=0x39c891d04311 <undefined>,q=0x5a024bf3be1 <JS Array[2241635]>,r=2241635,F=0x39c891d043b1 <true>,B=0x39c891ddafe9 <String[1]\: \n>,A=0x39c891d04421 <false>)
2: Join(aka Join) [native array.js:~122] [pc=0x5d1fb5cde96](this=0x39c891d04311 <undefined>,q=0x5a024bf3be1 <JS Array[2241635]>,r=2241635,B=0x39c891ddafe9 <String[1...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/Users/erossignon/.nvm/versions/node/v7.2.0/bin/node]
2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/erossignon/.nvm/versions/node/v7.2.0/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/erossignon/.nvm/versions/node/v7.2.0/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/Users/erossignon/.nvm/versions/node/v7.2.0/bin/node]
5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/erossignon/.nvm/versions/node/v7.2.0/bin/node]
6: 0x5d1faa063a7
Abort trap: 6
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory这个是报错的症结词，平常也是我们检索的症结词，至于为何会致使这个缺点，报错信息就显现JavaScript堆内存不足，信息中也显现了近来频频GC的概况，GC(Garbage collection
)是渣滓接纳机制，详细能够浏览一下JavaScript 内存走漏教程。经由开端相识，就是我们的运用内容泄漏的，平常治标不治本的处理计划就是加大Node.js运转时内存中保存的“未运用”空间量：
node --max-old-space-size=4096 yourFile.js
JavaScript heap out of memory的缘由及处理计划
Node运转时V8内存的限定
Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine.，平常情况下，Node在运转时只能运用到体系的一部份内存，64位体系下约为1.4GB，32位体系下约为0.7GB【有待考据，出处@JerryC】。当GC时，假如须生区大小凌驾设定的值时，就会报错。
平常处理计划：
在启动node顺序的时刻，能够通报两个参数来调解内存限定的大小，消除默许的限定
如
node --max-nex-space-size=1024 app.js // 单元为KB
node --max-old-space-size=2000 app.js // 单元为MB实践中的处理能够会有以下操纵：
set NODE_ENV=production && node --max_old_space_size=2048 node_modules/webpack/bin/webpack.js --config webpack.production.config.jsyarn serve – JavaScript heap out of memory crash
"dev": "npx --max_old_space_size=4096 vue-cli-service serve"
代码题目
除了环境题目，最症结的题目就是代码自身存在题目，毕竟上面的要领治标不治本，要根治这个缺点，能够须要审阅代码，先监测到内存走漏的缘由，把这部份代码找出优化。平常是无限定增进的数组、无限定设置属性和值、大循环等【出处:@林小新】。这部份因为Copy攻城狮并为深切，能够参考怎样定位Node.js 的内存走漏、node内存走漏以及定位
