起因

項目中使用了nuxtjs框架進行開發，在開發測試過程中均無出現任何異常。部署上線到正式生產環境之后，運行了五六天之后node異常，服務停止響應，pm2管理平臺無法恢復應用程序。需要進入生產環境進行重啟項目。查閱運行日志之后發現生產服務器會緩慢堆積tcp鏈接。在到一定的程度之后，會引發node程序 cpu 100%占用，停止響應。最初階段以為是_nuxt下的文件并未通過nginx訪問，而是通過node進行讀取的，造成文件打開過多，重新配置了nginx靜態文件讀取規則之后，問題依舊。在解決這個問題的過程中發現某個文章中提到，如果node內存泄漏會造成node進程跑滿當前cpu,并且打開文件數飆增。

調試

調試工具

node-heapdump

chrome調試工具

調試流程

安裝node-heapdump。

npm install node-heapdump --save-dev

打開項目根目錄的nuxt.config.js文件，進行heapdump配置。

// 內存快照代碼var headpdump = require('heapdump') //setInterval(function () {console.log('st headpdump')headpdump.writeSnapshot(function(err, filename) {console.log('dump written to', filename)})}, 15000)module.exports = {...// nuxt配置}

我設定了每1.5秒,heapdump進行內存快照一次。
并且在間隔過程中進行以下操作。

載入頁面，等候一次快照

刷新一次頁面，等候一次快照

等待快照完成之后，heapdump會將快照文件保存在項目根目錄中。

接著，我們打開chrome開發者工具，切換到memory選項卡，點擊load載入hepdump生成在根目錄的文件。

分別載入第一次頁面快照，跟刷新一次之后的快照。我們點擊切換右側下拉箭頭的視圖選項卡類型。點擊切換視圖到Comparison。

在等候Chrome比對兩個文件之后，可以看到第二個文件的內存快照信息。查看右側# Delta選項。

可以看到 刷新一次之后，增加了69個閉包未釋放。
展開閉包(closure)可以看到大量的request請求未釋放。
由此可見，問題出現在項目中服務端請求服務接口上。

解決問題

檢查services文件中的請求方法代碼。

import Urls from './url' import Fetch from './fetch.js'let fn = {} Object.keys(Urls).forEach(key => {fn[key] = (data, headers) => {return new Promise((resolve, reject) => {resolve(Fetch(Urls[key].url, {method: Urls[key].method, data, headers}))})} })export default fn

發現了問題，services 通過return請求，但是使用的數據都是通過箭頭方法傳遞到下一層，變量被層層引用，這樣會造成閉包無法完全釋放。因為傳入的數據一直都有引用無法gc，這樣也造成了node打開的tcp鏈接無法關閉釋放。

我們修改了services方法，經過修改的代碼如下:

import Urls from './url' import Fetch from './fetch.js'let fn = {} Object.keys(Urls).forEach(key => {fn[key] = function (data, headers) {return Fetch(Urls[key].url, {method: Urls[key].method, data, headers})} })export default fn

再次通過調試流程生成內存快照，發現request閉包都回收完畢。內存泄漏問題初步告一段落，項目更新之后已穩定運行。

參考文章來源
http://frontenddev.org/link/j...

文章初次發布于https://www.yodfz.com/detail/...

總結

以上是生活随笔為你收集整理的NUXT内存泄漏引发问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。