浅谈VueJS SSR 后端绘制内存泄漏的相关解决经验

引言

Memory Leak 是最难排查调试的 Bug 种类之一,因为内存泄漏是个 undecidable problem,只有开发者才能明确一块内存是不是需要被回收。再加上内存泄漏也没有特定的报错信息,只能通过一定时间段的日志来判断是否存在内存泄漏。大家熟悉的常用调试工具对排查内存泄漏也没有用武之地。当然了,除了专门用于排查内存泄漏的工具(抓取Heap之类的工具)之外。

对于不同的语言,各种排查内存泄漏的方式方法也不尽相同。对于 JavaScript 来说,针对不同的平台,调试工具也是不一样的,最常用的恐怕还是 Chrome 自带的各种利器(针对 browser 也好,nodeJS 也好)都有不错的使用体验,网上也有很多使用教程。

这次我想给大家介绍的内存泄漏的定位方法,并非工具的使用。而是一些经验的总结,也就是我所知道的 VueJS SSR 中最容易出现内存泄漏的地方,如果大家知道更多 VueJS SSR 内存泄漏点,可以在评论处留言告诉更多的人。

难点

遇到过 VueJS SSR 内存泄漏的朋友可能知道,针对 VueJS SSR 内存泄漏的排查,与普通 NodeJS 和 Browser 平台相比是要麻烦很多的。如果你使用了 webpack-dev-server 在本地调试,你会发现常用的内存泄漏工具毫无用武之地,因为抓取到的信息不仅包括 VueJS SSR 进程信息,还包含了 Webpack 的进程信息,甚至还有 webpack-dev-server 的各种堆信息。当然了,你也可以通过各种手段来过滤掉无关的信息,从而只剩下 VueJS SSR 的堆信息。

我在排查我们组项目内存泄漏的时候,动用了各种常规工具,但最终发现 VueJS SSR 的内存泄漏有很大可能性出现在以下地方,也就说如果,你碰巧也有 VueJS SSR 内存泄漏的问题,先不要使用内存泄漏排查工具,首先从下面几个地方着手,看看是否有内存泄漏的逻辑。可能直击要害,节约时间。

可能造成泄漏的位置

生命周期处的 beforeCreate/created

以下是 VueJS 开发者看过无数次的说明图,我还请大家再多看一遍

在官方文档里,有这么一句话:

Since there are no dynamic updates, of all the lifecycle hooks, only beforeCreate and created will be called during SSR. This means any code inside other lifecycle hooks such as beforeMount or mounted will only be executed on the client.

也就是说 SSR 跟前端绘制一样,也有生命周期,只不过 SSR 的生命周期里只有 beforeCreate 和 created 。

所以你需要首先排查你的组件的 beforeCreate 和 created 里面是否有内存泄漏的代码,或者他们是否调用了会内存泄漏的代码。

路由守卫(Route Guards)处

路由也是会引起 SSR 内存泄漏的地方之一

跟生命周期不同,所有的 route guard 都会在 SSR 运行。他们分别都是

  • beforeEach
  • beforeRouteUpdate
  • beforeEnter
  • beforeRouteEnter
  • beforeResolve
  • afterEach
  • beforeRouteEnter

Data-Prefetch 处

还需要特别注意的地方就是 Date-prefetch 的地方,里面很容易出现内存泄漏的代码。 所谓 Date-prefetch 就是自定义实现的,在SSR处提前获取第三方数据,用于绘制的过程。

Global Mixin 处

这个内存泄漏的点想必大家都已经熟知,作者也在github上详细阐述过:GitHub issue

简单来说,就是 global mixin 会给每个 Vue 实例一个拷贝,而不是引用。

内存泄漏的例子

以上列举了一些可能出现内存泄漏的地方,那么具体怎么样的代码才会引起内存泄漏呢?引起代码泄漏的例子网上有很多,我在这里想给大家介绍几种常见的泄漏例子。

不小心造成的全局变量

function foo(arg) {
 bar = "this is a hidden global variable";
}

以上的代码会顺利运行,但是因为不小心声明了一个 bar 的变量。相当于:

function foo(arg) {
 window.bar = "this is an explicit global variable";
}

生成了一个全局变量 window.bar

如果不手动回收,这个全局变量会一直存在于内存中,不会被CG回收。积少成多,最后造成内存泄漏。

现在大家都是在各种模块化(CommonJS/AMD/CMD/etc..)之后的环境下进行开发,这种全局变量的内存泄漏的问题基本上是被消除了。但是要提醒大家,由于JavaScript的各种特性,会有很多意想不到的状况发生。当摸不清头脑的时候,可以尝试从这些特性出发找到问题。

被遗忘了的 Timer 或者 callback

请大家先看以下的例子

var someResource = getData();
setInterval(function() {
 var node = document.getElementById('Node');
 if(node) {
 // Do stuff with node and someResource.
 node.innerHTML = JSON.stringify(someResource));
 }
}, 1000);

乍一看没啥问题,之后如果 Node 节点从DOM上被移除,因为上面的 callback 对 Node 节点有引用,所以 Node 节点会一直常驻内存,不会被CG回收。

要避免以上问题,就要养成 removeEventListenerclearInterval 的习惯。

var someResource = getData();
var interval = setInterval(function() {
 var node = document.getElementById('Node');
 if(node) {
 // Do stuff with node and someResource.
 node.innerHTML = JSON.stringify(someResource));
 } else {
 // Remove Timer
 clearInterval(interval);
 }
}, 1000);

还比如:

var element = document.getElementById('button');

function onClick(event) {
 element.innerHtml = 'text';
}

element.addEventListener('click', onClick);
// Do stuff
element.removeEventListener('click', onClick);
element.parentNode.removeChild(element);
// Now when element goes out of scope,
// both element and onClick will be collected even in old browsers that don't
// handle cycles well.

addEventListener 之后已经要记得 removeEventListener

闭包

闭包造成内存泄漏的情况比较复杂,而且较难查找。限于本文主旨,不做原理说明。

总结

个人认为 VueJS SSR 后端绘制内存泄漏造成影响要比普通的 VueJS 前端内存泄漏造成的影响要更大。

前端内存泄漏的影响,都是发生在客户机器上,而且基本上现代浏览器也会做好保护机制,一般自行刷新之后都会解决。但是,一旦后端绘制内存泄漏造成宕机之后,整个服务器都会受影响,危险性更大,搞不好年终奖就没了。

前端工程师一般都是关注于浏览器端表现,在开发过程中的内存泄漏问题不太在意也不太容易被发现。一般都是在项目上线一段时间之后,才发现内存泄漏的情况。那个时候再去着手,可能会有些无从下手或者手忙脚乱。

那么,就让我们在开发的时候开始关注内存泄漏问题,将 VueJS SSR 后端绘制内存泄漏问题扼杀于襁褓之中。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 简单的Vue SSR的示例代码

    前言 最近接手一个老项目,典型的 Vue 组件化前端渲染,后续业务优化可能会朝 SSR 方向走,因此,就先做些技术储备.如果对 Vue SSR 完全不了解,请先阅读官方文档. 思路 Vue 提供了一个官方 Demo,该 Demo 优点是功能大而全,缺点是对新手不友好,容易让人看蒙.因此,今天我们来写一个更加容易上手的 Demo.总共分三步走,循序渐进. 写一个简单的前端渲染 Demo(不包含 Ajax 数据): 将前端渲染改成后端渲染(仍然不包含 Ajax 数据): 在后端渲染的基础上,加上 A

  • 基于vue-ssr的静态网站生成器VuePress 初体验

    什么是VuePress VuePress由两部分组成:一个基于Vue的轻量级静态网站生成器,以及为编写技术文档而优化的默认主题. 它是为了满足Vue自己的子项目文档的需求而创建的. VuePress为每一个由它生成的页面提供预加载的html,不仅加载速度极佳,同时对seo非常友好.一旦页面被加载之后,Vue就全面接管所有的静态内容,使其变成一个完全的SPA应用,其他的页面也会在用户使用导航进入的时候来按需加载. 参考官方文档可知该项目有一下特点: 内置markdown(基础功能) 支持PWA 集

  • Vue2 SSR渲染根据不同页面修改 meta

    本文主要介绍了Vue2 SSR渲染根据不同页面修改 meta,分享给大家,具体如下: 注意: 经过测试, vue-meta 会导致内存泄漏, 请慎用- 以现在 vue2 的 服务端渲染模式, 都是通过 webpack 生成 html 模版文件(或者直接在 server.js 里拼接), 然后通过fs.readFileSync 读取该文件, 再通过 res.end 输出, 这样就造成 meta 修改很麻烦 这时候我们可以借助 vue-meta 来管理, 下面以官方的vue-hackernews-2

  • 通过vue-cli3构建一个SSR应用程序的方法

    1.前沿 1.1.什么是SSR SSR(服务端渲染)顾名思义就是将页面在服务端渲染完成后在客户端直接展示. 1.2.客户端渲染与服务端渲染的区别 传统的SPA模式 即客户端渲染的模式 Vue.js构建的应用程序,默认情况下是有一个html模板页,然后通过webpack打包生成一堆js.css等等资源文件.然后塞到index.html中 用户输入url访问页面 -> 先得到一个html模板页 -> 然后通过异步请求服务端数据 -> 得到服务端的数据 -> 渲染成局部页面 ->

  • 详解Vue2 SSR 缓存 Api 数据

    本文介绍了Vue2 SSR 缓存 Api 数据,分享给大家,具体如下: 1. 安装缓存依赖: lru-cache npm install lru-cache --dev 2. api 配置文件 config-server.js var LRU = require('lru-cache') let api if (process.__API__) { api = process.__API__ } else { api = process.__API__ = { api: 'http://loca

  • Vue SSR 组件加载问题

    Node 端渲染提示 window/document 没有定义 业务场景 首先来看一个简单的 Vue 组件 test.vue <template> <div> <h2>clientHeight: {{ clientHeight }} px </h2> </div> </template> <script type="text/babel"> export default { data(){ return

  • 基于vue-ssr服务端渲染入门详解

    第一部分 基本介绍 1.前言 服务端渲染实现原理机制:在服务端拿数据进行解析渲染,直接生成html片段返回给前端.然后前端可以通过解析后端返回的html片段到前端页面,大致有以下两种形式: 1.服务器通过模版引擎直接渲染整个页面,例如java后端的vm模版引擎,php后端的smarty模版引擎. 2.服务渲染生成html代码块, 前端通过AJAX获取然后使用js动态添加. 2.服务端渲染的优劣 服务端渲染能够解决两大问题: 1.seo问题,有利于搜索引擎蜘蛛抓取网站内容,利于网站的收录和排名.

  • vue ssr 指南详读

    本帖说明 该贴是对vue SSR Guide解读和补充,对于官网文档已有内容会以引用方式体现.由于官网demo在国内无法运行,该贴最后也提供了一个完整的可以运行的demo,帖子中提到的代码均是来自于该demo,供学习交流. 介绍 什么是服务器端渲染(SSR)? Vue.js 是构建客户端应用程序的框架.默认情况下,可以在浏览器中输出 Vue 组件,进行生成 DOM 和操作 DOM.然而,也可以将同一个组件渲染为服务器端的 HTML 字符串,将它们直接发送到浏览器,最后将静态标记"混合"

  • 详解vue服务端渲染(SSR)初探

    前言 首先来讲一下服务端渲染,直白的说就是在服务端拿数据进行解析渲染,直接生成html片段返回给前端.具体用法也有很多种比如: 传统的服务端模板引擎渲染整个页面 服务渲染生成htmll代码块, 前端 AJAX 获取然后js动态添加 服务端渲染的优劣 首先是seo问题,前端动态渲染的内容是不能被抓取到的,而使用服务端渲染就可以解决这个问题.还有就是首屏加载过慢这种问题,比如在SPA中,打开首页需要初始加载很多资源,这时考虑在首屏使用服务端渲染,也是一种折中的优化方案.但是使用SSR时,势必会增加服

  • 浅谈Vue SSR 的 Cookies 问题

    一个网站一旦涉及到多用户, 就很难从 Cookies 中逃脱, Vue SSR 的 cookies 也真算是遇到的一个不小的问题, 从开始玩 SSR 开始到现在, 一共想出了3种方案, 从最早的把 Cookies 注入到 state 中, 到把 Cookies 注入到 global, 到现在的将 Cookies 注入到组件的 asyncData 方法. 随着 Vue 的升级, 第一种方案已经不再适用, 第二种也有不少的限制, 于是想到第三种方案, 下来就说说具体实现的方法: 第一种方案 第一种方

  • 最后说说Vue2 SSR 的 Cookies 问题

    本来想前面写点什么的, 还是算了, 直接说思路吧. 从 Vue2.3 版本后, SSR 的 cookies, 就变成一个无比麻烦的问题, 具体请访问官网文档: https://ssr.vuejs.org/zh/api.html#runinnewcontext 之前也说不少的思路, 可是都觉得不怎么好用, 虽然都能解决问题, 今天再说一种思路 因为 Vue2.3 以后, bundle 代码将与服务器进程在同一个 global 上下文中运行, 所以不能再将 cookies 丢到 global 给 a

随机推荐