資訊專欄INFORMATION COLUMN
摘要：當時，如果老生區(qū)大小超過設定的值時，就會報錯。一般是無限制增長的數(shù)組無限制設置屬性和值大循環(huán)等出處林小新。這部分由于攻城獅并為深入，可以參考如何定位的內(nèi)存泄漏內(nèi)存泄漏以及定位
↑開局一張圖，故事全靠編↑
這是一個很狗血的故事，故事的開頭是一個項目，這個項目十分草率，草率到什么程度？沒有設計稿，沒有文檔，需求全靠口口相傳，當然最草率的是交給了我，我簡單列了下需求：
官網(wǎng)的形式，主要介紹公司某些業(yè)務
要能發(fā)文章
盡管很簡單的需求，對于水得一匹的我來說，簡直是“難于上青天”，三大件(html,css,javascript)我樣樣精通個P，網(wǎng)站部署我也只略知一二，代碼編水平更是不學無術。作為Copy工程師，遇到需求我便開始了copy之路，先github溜達了一圈，找了幾個滿足需求的項目，最終對比了一下，選擇了一個名叫iBlog2的項目--基于 Node.js 的個人開源博客系統(tǒng)。您沒看錯，就是一個博客系統(tǒng)！這跟官網(wǎng)有個毛關系？這個宕機又有個毛關系？我想說的是，經(jīng)過copy然后小改之后，iBlog2搖身一變就成了能發(fā)布文章的官網(wǎng)項目，就是這么簡單粗暴，就是這么不學無術(溫馨提示：少壯不努力，老大偷代碼)。
這個3年之前的項目，在現(xiàn)在看來的確是有些陳舊，但作者@eshengsky依舊堅持不懈的在更新維護,而對于我而言，只是為了完成能發(fā)文章的官網(wǎng)，所以只關注文章是如何發(fā)布和儲存的，恰恰是因為我關注的面窄，忽略了部署和部署之后可能會遇到的各種問題，比如window下pm2可能出現(xiàn)問題、比如這次的JavaScript heap out of memory。當然并不是人家開源項目有問題，而是實際部署的時候壓根沒按照作者的文檔來，如果按照文檔，我應該用pm2部署，或者啟用redis，或者使用Noginx,或者使用本機的MongoDB服務，然而，這一切，我只是在我們那個服務器新開了個端口，然后直接npm run dev就開始跑在線上了，所以呢，這么“銹”的操作，不宕機才是天理難容，印象中JavaScript heap out of memory遇到兩次了，才兩三個月啊！
檢索JavaScript heap out of memory通常遇到問題，我首選的解決流程是打開Chrome--輸入關鍵詞--搜索--瀏覽--copy--嘗試，好像從來沒有去思考過產(chǎn)生問題的根源，甚至都沒有去記錄這個問題以及解決的方案，導致再遇到同樣的坑，又掉進去了，然后又是一通檢索嘗試等操作，這也是我從業(yè)這么多年來，一直沒養(yǎng)成的習慣，也是這么多年一直沒成長的某一個小的原因，“少抱怨，多思考，未來會更美好”，而我一直以反面教材在詮釋這個金句。
通常來說，只要您的關鍵詞夠準確，您就能通過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
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這個是報錯的關鍵詞，通常也是我們檢索的關鍵詞，至于為什么會導致這個錯誤，報錯信息就顯示JavaScript堆內(nèi)存不足，信息中也顯示了最近幾次GC的詳情，GC(Garbage collection
)是垃圾回收機制，具體可以閱讀一下JavaScript 內(nèi)存泄漏教程。經(jīng)過初步了解，就是我們的應用內(nèi)容泄露的，通常治標不治本的解決方案就是加大Node.js運行時內(nèi)存中保留的“未使用”空間量：
node --max-old-space-size=4096 yourFile.jsJavaScript heap out of memory的原因及解決方案 Node運行時V8內(nèi)存的限制
Node.js? is a JavaScript runtime built on Chrome"s V8 JavaScript engine.，一般情況下，Node在運行時只能使用到系統(tǒng)的一部分內(nèi)存，64位系統(tǒng)下約為1.4GB，32位系統(tǒng)下約為0.7GB【有待考證，出處@JerryC】。當GC時，如果老生區(qū)大小超過設定的值時，就會報錯。
一般解決方案：
在啟動node程序的時候，可以傳遞兩個參數(shù)來調(diào)整內(nèi)存限制的大小，解除默認的限制
如
node --max-nex-space-size=1024 app.js // 單位為KB node --max-old-space-size=2000 app.js // 單位為MB
實踐中的解決可能會有以下操作：
項目運行wepack打包時出現(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)境問題，最關鍵的問題就是代碼本身存在問題，畢竟上面的方法治標不治本，要根治這個毛病，可能需要審視代碼，先監(jiān)測到內(nèi)存泄漏的原因，把這部分代碼找出優(yōu)化。一般是無限制增長的數(shù)組、無限制設置屬性和值、大循環(huán)等【出處:@林小新】。這部分由于Copy攻城獅并為深入，可以參考如何定位Node.js 的內(nèi)存泄漏、node內(nèi)存泄漏以及定位
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/101292.html
摘要：根據(jù)當時的情境，是在微信開發(fā)者工具中刪掉該小程序然后重新載入就解決了，大家給出的結論是微信小程序開發(fā)者工具的。 Created 2019-4-2 22:17:34 by huqiUpdated 2019-4-2 23:17:34 by huqishowImg(https://segmentfault.com/img/bVbqOLH?w=1526&h=818); ↑開局一張圖，故事全靠編...
摘要：依舊是很簡單的需求，但是對于資深的攻城獅來說，除了布局，其他的就只能去了。特別是真機跑的時候，問題特別多。還是坑在基礎不牢固，文檔看得不深入，對小程序原生組件應該注意的事項把握不準，才會掉入這個非常基礎的坑。 Created 2019-4-3 18:29:53 by huqiUpdated 2019-4-3 19:12:22 by huqi showImg(https://segmen...
摘要：接下來，在支付寶小程序開發(fā)者工具中打，不出意外能跑起來一個電商支付寶小程序雛形。地址以上是我這個攻城獅對使用轉換原生微信小程序為支付寶小程序的一次微不足道的實踐。 showImg(https://segmentfault.com/img/bVbnCCN?w=1818&h=931);↑開局一張圖，故事全靠編↑ 從一個需求說起 作為底層的程序猿，哦不，我連猿都算不上，混的好的叫碼神，混得一...
摘要：開局一張圖，故事全靠編是啥變色龍又是啥自從有小程序以來，小程序的第三方框架便孕育而生，從原始時代的只基于微信小程序多如今多端統(tǒng)一開發(fā)框架，可以說前端技術從年到年又發(fā)生了天翻地覆的變化。 Created 2019-4-6 21:57:17 by huqi Updated 2019-4-7 22:54:55 by huqi showImg(https://segmentfault.c...
摘要：工作日，每天起床機械地去上班，周末，每天優(yōu)哉游哉，好像一個木偶，被生活蹂躪的木偶，意識以外的力量在操縱著的木偶。支持子節(jié)點數(shù)據(jù)異步加載。當然，官方將提供更改鍵值的。本許可協(xié)議授權之外的使用權限可以從處獲得。 Created by huqi at 2019-5-18 10:32:30 Updated by huqi at 2019-5-18 12:32:23 showImg(http...
閱讀 2340·2021-09-30 09:47
閱讀 2959·2019-08-30 11:05
閱讀 2533·2019-08-29 17:20
閱讀 1921·2019-08-29 13:01
閱讀 1727·2019-08-26 13:39
閱讀 1249·2019-08-26 13:26
閱讀 3210·2019-08-23 18:40
閱讀 1827·2019-08-23 17:09
