摘要：當(dāng)時(shí)，如果老生區(qū)大小超過(guò)設(shè)定的值時(shí)，就會(huì)報(bào)錯(cuò)。一般是無(wú)限制增長(zhǎng)的數(shù)組無(wú)限制設(shè)置屬性和值大循環(huán)等出處林小新。這部分由于攻城獅并為深入，可以參考如何定位的內(nèi)存泄漏內(nèi)存泄漏以及定位

↑開局一張圖，故事全靠編↑

這是一個(gè)很狗血的故事，故事的開頭是一個(gè)項(xiàng)目，這個(gè)項(xiàng)目十分草率，草率到什么程度？沒有設(shè)計(jì)稿，沒有文檔，需求全靠口口相傳，當(dāng)然最草率的是交給了我，我簡(jiǎn)單列了下需求：

官網(wǎng)的形式，主要介紹公司某些業(yè)務(wù)

要能發(fā)文章

盡管很簡(jiǎn)單的需求，對(duì)于水得一匹的我來(lái)說(shuō)，簡(jiǎn)直是“難于上青天”，三大件(html,css,javascript)我樣樣精通個(gè)P，網(wǎng)站部署我也只略知一二，代碼編水平更是不學(xué)無(wú)術(shù)。作為Copy工程師，遇到需求我便開始了copy之路，先github溜達(dá)了一圈，找了幾個(gè)滿足需求的項(xiàng)目，最終對(duì)比了一下，選擇了一個(gè)名叫iBlog2的項(xiàng)目--基于 Node.js 的個(gè)人開源博客系統(tǒng)。您沒看錯(cuò)，就是一個(gè)博客系統(tǒng)！這跟官網(wǎng)有個(gè)毛關(guān)系？這個(gè)宕機(jī)又有個(gè)毛關(guān)系？我想說(shuō)的是，經(jīng)過(guò)copy然后小改之后，iBlog2搖身一變就成了能發(fā)布文章的官網(wǎng)項(xiàng)目，就是這么簡(jiǎn)單粗暴，就是這么不學(xué)無(wú)術(shù)(溫馨提示：少壯不努力，老大偷代碼)。

這個(gè)3年之前的項(xiàng)目，在現(xiàn)在看來(lái)的確是有些陳舊，但作者@eshengsky依舊堅(jiān)持不懈的在更新維護(hù),而對(duì)于我而言，只是為了完成能發(fā)文章的官網(wǎng)，所以只關(guān)注文章是如何發(fā)布和儲(chǔ)存的，恰恰是因?yàn)槲谊P(guān)注的面窄，忽略了部署和部署之后可能會(huì)遇到的各種問題，比如window下pm2可能出現(xiàn)問題、比如這次的JavaScript heap out of memory。當(dāng)然并不是人家開源項(xiàng)目有問題，而是實(shí)際部署的時(shí)候壓根沒按照作者的文檔來(lái)，如果按照文檔，我應(yīng)該用pm2部署，或者啟用redis，或者使用Noginx,或者使用本機(jī)的MongoDB服務(wù)，然而，這一切，我只是在我們那個(gè)服務(wù)器新開了個(gè)端口，然后直接npm run dev就開始跑在線上了，所以呢，這么“銹”的操作，不宕機(jī)才是天理難容，印象中JavaScript heap out of memory遇到兩次了，才兩三個(gè)月??！

通常遇到問題，我首選的解決流程是打開Chrome--輸入關(guān)鍵詞--搜索--瀏覽--copy--嘗試，好像從來(lái)沒有去思考過(guò)產(chǎn)生問題的根源，甚至都沒有去記錄這個(gè)問題以及解決的方案，導(dǎo)致再遇到同樣的坑，又掉進(jìn)去了，然后又是一通檢索嘗試等操作，這也是我從業(yè)這么多年來(lái)，一直沒養(yǎng)成的習(xí)慣，也是這么多年一直沒成長(zhǎng)的某一個(gè)小的原因，“少抱怨，多思考，未來(lái)會(huì)更美好”，而我一直以反面教材在詮釋這個(gè)金句。

通常來(lái)說(shuō)，只要您的關(guān)鍵詞夠準(zhǔn)確，您就能通過(guò)google搜索找到盡可能滿意的解決方案，如果連關(guān)鍵詞都沒把握好，我想就算請(qǐng)教的大牛，也不一定能有效的回答，當(dāng)然思否和Stack Overflow都可能有填您那個(gè)坑的“鐵楸”，還有一個(gè)陣地就是github。

通常來(lái)說(shuō)，程序報(bào)錯(cuò)一般都有詳細(xì)的報(bào)錯(cuò)說(shuō)明，比如哪一行、出了什么錯(cuò)、出錯(cuò)明細(xì)等，就比如文章開頭的那張報(bào)錯(cuò)圖，我找到了其他用戶遇到的一模一樣的問題：

    <--- 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 
        1: DoJoin(aka DoJoin) [native array.js:~97] [pc=0x5d1facabad4](this=0x39c891d04311 ,q=0x5a024bf3be1 ,r=2241635,F=0x39c891d043b1 ,B=0x39c891ddafe9 ,A=0x39c891d04421 )
        2: Join(aka Join) [native array.js:~122] [pc=0x5d1fb5cde96](this=0x39c891d04311 ,q=0x5a024bf3be1 ,r=2241635,B=0x39c891ddafe9 , v8::Local) [/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這個(gè)是報(bào)錯(cuò)的關(guān)鍵詞，通常也是我們檢索的關(guān)鍵詞，至于為什么會(huì)導(dǎo)致這個(gè)錯(cuò)誤，報(bào)錯(cuò)信息就顯示JavaScript堆內(nèi)存不足，信息中也顯示了最近幾次GC的詳情，GC(Garbage collection
)是垃圾回收機(jī)制，具體可以閱讀一下JavaScript 內(nèi)存泄漏教程。經(jīng)過(guò)初步了解，就是我們的應(yīng)用內(nèi)容泄露的，通常治標(biāo)不治本的解決方案就是加大Node.js運(yùn)行時(shí)內(nèi)存中保留的“未使用”空間量：

node --max-old-space-size=4096 yourFile.js

Node.js? is a JavaScript runtime built on Chrome"s V8 JavaScript engine.，一般情況下，Node在運(yùn)行時(shí)只能使用到系統(tǒng)的一部分內(nèi)存，64位系統(tǒng)下約為1.4GB，32位系統(tǒng)下約為0.7GB【有待考證，出處@JerryC】。當(dāng)GC時(shí)，如果老生區(qū)大小超過(guò)設(shè)定的值時(shí)，就會(huì)報(bào)錯(cuò)。
一般解決方案：
在啟動(dòng)node程序的時(shí)候，可以傳遞兩個(gè)參數(shù)來(lái)調(diào)整內(nèi)存限制的大小，解除默認(rèn)的限制
如

node --max-nex-space-size=1024 app.js // 單位為KB
node --max-old-space-size=2000 app.js // 單位為MB

實(shí)踐中的解決可能會(huì)有以下操作：

項(xiàng)目運(yùn)行wepack打包時(shí)出現(xiàn)內(nèi)存泄漏問題經(jīng)常拋異常

   set NODE_ENV=production && node --max_old_space_size=2048 node_modules/webpack/bin/webpack.js --config webpack.production.config.js

yarn serve - JavaScript heap out of memory crash

 "dev": "npx --max_old_space_size=4096 vue-cli-service serve"

除了環(huán)境問題，最關(guān)鍵的問題就是代碼本身存在問題，畢竟上面的方法治標(biāo)不治本，要根治這個(gè)毛病，可能需要審視代碼，先監(jiān)測(cè)到內(nèi)存泄漏的原因，把這部分代碼找出優(yōu)化。一般是無(wú)限制增長(zhǎng)的數(shù)組、無(wú)限制設(shè)置屬性和值、大循環(huán)等【出處:@林小新】。這部分由于Copy攻城獅并為深入，可以參考如何定位Node.js 的內(nèi)存泄漏、node內(nèi)存泄漏以及定位