【Copy攻城獅日誌】聊聊JavaScript heap out of memory

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

---

從一次宕機提及

這是一個很狗血的故事，故事的開頭是一個項目，這個項目十分草率，草率到什麼程度？沒有設計稿，沒有文檔，需求全靠口口相傳，固然最草率的是交給了我，我簡單列了下需求：

• 官網的形式，主要介紹公司某些業務
• 要能發文章

儘管很簡單的需求，對於水得一匹的我來講，簡直是「難於上青天」，三大件(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

實踐中的解決可能會有如下操做：

• 項目運行wepack打包時出現內存泄漏問題常常拋異常

  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"

代碼問題

除了環境問題，最關鍵的問題就是代碼自己存在問題，畢竟上面的方法治標不治本，要根治這個毛病，可能須要審視代碼，先監測到內存泄漏的緣由，把這部分代碼找出優化。通常是無限制增加的數組、無限制設置屬性和值、大循環等【出處:@林小新】。這部分因爲Copy攻城獅併爲深刻，能夠參考如何定位Node.js 的內存泄漏、node內存泄漏以及定位