搜寻资料
Webpack 内存泄漏issue https://github.com/webpack/webpack/issues/6929
几个问题:
Chrome devtool bug https://bugs.chromium.org/p/chromium/issues/detail?id=852746
Webpack版本 https://github.com/webpack/webpack/releases/tag/v4.18.1(当前4.16.1)
Webpack plugin问题, e.g postcss-loader 2.1.6 修复内存泄漏问题(当前2.1.5)
验证问题
一开始通过使用nodemon --inspect配合Chrome的inspect工具,进行内存快照,可以发现以下现象:
CSS变动每次热更新一行代码变动大约增加24-25MB,即使只是加一行,删除刚刚那一行,每次操作都会增加内存,甚至原地保存也可能增加1MB,存在内存泄漏嫌疑。
尝试修复
升级 postcss-loader 3.0.0 和webpack 4.22.0 后,修改SCSS文件的热更新不再增加内存耗用,有效!
不知道为什么,take heap snapshot 很偶尔能成功,通常总会导致程序crash。所以尝试使用另一个方法——Allocation instrumentation on timeline
运行npm run dev,在webpack编译文件前立刻开启录制,可以完整的观察到内存使用变化情况,但是会降低运行速度。正常情况下几秒钟可以完成的编译,会因为这个录制减速到几分钟。
但我仍然坚持了下来
对于同样的操作:1 初次编译 —— 2 增加约100行SCSS代码 —— 3 改动SCSS缩进—— 4 删除刚增加的SCSS代码
升级依赖前
可以看到内存在稳步增长,每次热更新编译时,之前占用的内存未能较好的释放(仅释放了一小部分)。
// 下面这个我忘了改了啥,反正就是还在涨。。。
升级依赖后
可以感受到,之前编译SCSS相关的内存几乎都被释放掉了(灰色部分),几次操作下来,内存占用稳定,相比于20+MB的稳定增长,效果要好很多!
结论
关于SCSS文件热更新导致的内存泄漏程序崩溃,得到了真实缓解。
按照之前的节奏,保存40次SCSS文件就可以迅速占用到1G以上内存,而现在,理论上可以撑住上千次保存操作,支持一天的开发续航(误
针对其他类型文件的变化尚未验证,但大致思路可以从各大webpack plugin入手
其他探索
依赖关系:
postcss-loader -> postcss-load-config -> cosmiconfig -> require-from-string
源头是 require-from-string的内存泄漏bug