【Copy攻城狮日志】聊聊JavaScript heap out of memory

paulquei 发布于2019-08-23 14:53 / 2148人阅读

摘要：当时，如果老生区大小超过设定的值时，就会报错。一般是无限制增长的数组无限制设置属性和值大循环等出处林小新。这部分由于攻城狮并为深入，可以参考如何定位的内存泄漏内存泄漏以及定位

↑开局一张图，故事全靠编↑

从一次宕机说起

这是一个很狗血的故事，故事的开头是一个项目，这个项目十分草率，草率到什么程度？没有设计稿，没有文档，需求全靠口口相传，当然最草率的是交给了我，我简单列了下需求：

官网的形式，主要介绍公司某些业务

要能发文章

尽管很简单的需求，对于水得一匹的我来说，简直是“难于上青天”，三大件(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 
        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堆内存不足，信息中也显示了最近几次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内存泄漏以及定位

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/101292.html

【Copy攻城狮日志】踩坑小程序之can't read property 'of

摘要：根据当时的情境，是在微信开发者工具中删掉该小程序然后重新载入就解决了，大家给出的结论是微信小程序开发者工具的。 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); ↑开局一张图，故事全靠编...

hsluoyz 2019-08-26 13:42 评论0 收藏0
【Copy攻城狮日志】踩坑小程序之canvas的显示层级问题

摘要：依旧是很简单的需求，但是对于资深的攻城狮来说，除了布局，其他的就只能去了。特别是真机跑的时候，问题特别多。还是坑在基础不牢固，文档看得不深入，对小程序原生组件应该注意的事项把握不准，才会掉入这个非常基础的坑。 Created 2019-4-3 18:29:53 by huqiUpdated 2019-4-3 19:12:22 by huqi showImg(https://segmen...

Coly 2019-08-23 16:43 评论0 收藏0
【Copy攻城狮日志】借助Taro暴改Nideshop实现电商支付宝小程序雏形

摘要：接下来，在支付宝小程序开发者工具中打，不出意外能跑起来一个电商支付宝小程序雏形。地址以上是我这个攻城狮对使用转换原生微信小程序为支付宝小程序的一次微不足道的实践。 showImg(https://segmentfault.com/img/bVbnCCN?w=1818&h=931);↑开局一张图，故事全靠编↑ 从一个需求说起作为底层的程序猿，哦不，我连猿都算不上，混的好的叫码神，混得一...

gnehc 2019-08-23 14:54 评论0 收藏0
【Copy攻城狮日志】CML之5分钟入门多端统一框架

摘要：开局一张图，故事全靠编是啥变色龙又是啥自从有小程序以来，小程序的第三方框架便孕育而生，从原始时代的只基于微信小程序多如今多端统一开发框架，可以说前端技术从年到年又发生了天翻地覆的变化。 Created 2019-4-6 21:57:17 by huqi Updated 2019-4-7 22:54:55 by huqi showImg(https://segmentfault.c...

MycLambert 2019-08-23 16:47 评论0 收藏0
【Copy攻城狮日志】"Error: if there's nested dat

摘要：工作日，每天起床机械地去上班，周末，每天优哉游哉，好像一个木偶，被生活蹂躏的木偶，意识以外的力量在操纵着的木偶。支持子节点数据异步加载。当然，官方将提供更改键值的。本许可协议授权之外的使用权限可以从处获得。 Created by huqi at 2019-5-18 10:32:30 Updated by huqi at 2019-5-18 12:32:23 showImg(http...

褰辩话 2019-08-26 13:50 评论0 收藏0