這篇文章將為大家詳細(xì)講解有關(guān)Node中堆內(nèi)存分配的示例分析，小編覺得挺實(shí)用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：主機(jī)域名、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、洪雅網(wǎng)站維護(hù)、網(wǎng)站推廣。

V8 垃圾回收簡介

首先，簡單介紹一下V8垃圾回收器。內(nèi)存的存儲分配方式是堆（heap），堆被分為幾個世代（generational）區(qū)域。 對象在它的生命周期中隨著年齡的變化，它所屬的世代也有所不同。

世代中分為年輕一代和老一代，而年輕的一代還分為了新生代和中間代。隨著對象在垃圾回收中幸存下來，它們也會加入老一代。

世代假說的基本原則是大多數(shù)對象都是年輕的。V8 垃圾回收器基于這一點(diǎn)，只提升在垃圾回收中幸存下來的對象。隨著對象被復(fù)制到相鄰區(qū)域，它們最終會進(jìn)入老一代。

在Nodejs中內(nèi)存消耗主要分為三個方面：

• 代碼-代碼執(zhí)行時所在的位置

• 調(diào)用棧-用于存放具有原始類型（數(shù)字，字符串或布爾值）的函數(shù)和局部變量

• 堆內(nèi)存

堆內(nèi)存是我們今天的主要關(guān)注點(diǎn)。 現(xiàn)在您對垃圾回收器有了更多的了解，是時候在堆上分配一些內(nèi)存了！

function allocateMemory(size) {
  // Simulate allocation of bytes
  const numbers = size / 8;
  const arr = [];
  arr.length = numbers;
  for (let i = 0; i < numbers; i++) {
    arr[i] = i;
  }
  return arr;
}

在調(diào)用棧中，局部變量隨著函數(shù)調(diào)用結(jié)束而銷毀?；A(chǔ)類型 number永遠(yuǎn)不會進(jìn)入堆內(nèi)存，而是在調(diào)用棧中分配。但是對象arr將進(jìn)入堆中并且可能在垃圾回收中幸存下來。

堆內(nèi)存有限制嗎？

現(xiàn)在進(jìn)行勇敢測試——將 Node 進(jìn)程推到極限看看在哪個地方會耗盡堆內(nèi)存：

const memoryLeakAllocations = [];

const field = "heapUsed";
const allocationStep = 10000 * 1024; // 10MB

const TIME_INTERVAL_IN_MSEC = 40;

setInterval(() => {
  const allocation = allocateMemory(allocationStep);

  memoryLeakAllocations.push(allocation);

  const mu = process.memoryUsage();
  // # bytes / KB / MB / GB
  const gbNow = mu[field] / 1024 / 1024 / 1024;
  const gbRounded = Math.round(gbNow * 100) / 100;

  console.log(`Heap allocated ${gbRounded} GB`);
}, TIME_INTERVAL_IN_MSEC);

在上面的代碼中，我們以 40 毫秒的間隔分配了大約 10 mb，為垃圾回收提供了足夠的時間來將幸存的對象提升到老年代。process.memoryUsage 是一個用于回收有關(guān)堆利用率的粗略指標(biāo)的工具。隨著堆分配的增長，heapUsed 字段會記錄堆的大小。這個字段記錄 RAM 中的字節(jié)數(shù)，可以轉(zhuǎn)換為mb。

你的結(jié)果可能會有所不同。在32GB 內(nèi)存的 Windows 10 筆記本電腦會得到以下結(jié)果：

Heap allocated 4 GB
Heap allocated 4.01 GB

<--- Last few GCs --->

[18820:000001A45B4680A0] 26146 ms: Mark-sweep (reduce) 4103.7 (4107.3) -> 4103.7 (4108.3) MB, 1196.5 / 0.0 ms (average mu = 0.112, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

在這里，垃圾回收器將嘗試壓縮內(nèi)存作為最后的手段，最后放棄并拋出“堆內(nèi)存不足”異常。這個過程達(dá)到了 4.1GB 的限制，需要 26.6 秒才能意識到要把服務(wù)給掛掉了。

導(dǎo)致以上結(jié)果的原因有些還未知。V8 垃圾回收器最初運(yùn)行在具有嚴(yán)格內(nèi)存限制的 32 位瀏覽器進(jìn)程中。這些結(jié)果表明內(nèi)存限制可能已經(jīng)從遺留代碼中繼承下來。

在撰寫本文時，以上代碼在最新的 LTS Node 版本下運(yùn)行，并且使用的是 64 位可執(zhí)行文件。從理論上講，一個 64 位進(jìn)程應(yīng)該能夠分配超過 4GB 的空間，并且可以輕松地增長到 16 TB 的地址空間。

擴(kuò)大內(nèi)存分配限制

node index.js --max-old-space-size=8000

這將最大限制設(shè)置為 8GB。這樣做時要小心。我的筆記本電腦有 32GB的空間。我建議將其設(shè)置為 RAM 中實(shí)際可用的空間。一旦物理內(nèi)存耗盡，進(jìn)程就會開始通過虛擬內(nèi)存占用磁盤空間。如果您將限制設(shè)置得太高，你就get了換電腦的新理由，這里咱們盡量避免電腦冒煙了哈~

我們再用8GB的限制再跑一次代碼：

Heap allocated 7.8 GB
Heap allocated 7.81 GB

<--- Last few GCs --->

[16976:000001ACB8FEB330] 45701 ms: Mark-sweep (reduce) 8000.2 (8005.3) -> 8000.2 (8006.3) MB, 1468.4 / 0.0 ms (average mu = 0.211, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

這一次堆的大小幾乎達(dá)到 8GB，但沒完全達(dá)到。我懷疑是Node 進(jìn)程中有一些開銷用于分配這么多內(nèi)存。這次進(jìn)程結(jié)束需要 45.7 秒。

在生產(chǎn)環(huán)境中，內(nèi)存全部用完可能不會少于一分鐘。這就是監(jiān)控和洞察內(nèi)存消耗有幫助的原因之一。內(nèi)存消耗會隨著時間的推移緩慢增長，并且可能需要幾天時間才能知道存在問題。如果進(jìn)程不斷崩潰并且日志中出現(xiàn)“堆內(nèi)存不足”異常，則代碼中可能存在內(nèi)存泄漏。

進(jìn)程也可能會占用更多內(nèi)存，因?yàn)樗谔幚砀鄶?shù)據(jù)。如果資源消耗繼續(xù)增長，可能是時候?qū)⑦@個單體分解為微服務(wù)了。這將減少單個進(jìn)程的內(nèi)存壓力，并允許節(jié)點(diǎn)水平擴(kuò)展。

如何跟蹤 Node.js 內(nèi)存泄漏

process.memoryUsage 的 heapUsed  字段還是有點(diǎn)用的，調(diào)試內(nèi)存泄漏的一個方法是將內(nèi)存指標(biāo)放在另一個工具中以進(jìn)行進(jìn)一步處理。由于此實(shí)現(xiàn)并不復(fù)雜，因此主要解析下如何親自實(shí)現(xiàn)。

const path = require("path");
const fs = require("fs");
const os = require("os");

const start = Date.now();
const LOG_FILE = path.join(__dirname, "memory-usage.csv");

fs.writeFile(LOG_FILE, "Time Alive (secs),Memory GB" + os.EOL, () => {}); // 請求-確認(rèn)

為了避免將堆分配指標(biāo)放在內(nèi)存中，我們選擇將結(jié)果寫入 CSV 文件以方便數(shù)據(jù)消耗。這里使用了 writeFile 帶有回調(diào)的異步函數(shù)。回調(diào)為空以寫入文件并繼續(xù)，無需任何進(jìn)一步處理。 要獲取漸進(jìn)式內(nèi)存指標(biāo)，請將其添加到 console.log：

const elapsedTimeInSecs = (Date.now() - start) / 1000;
const timeRounded = Math.round(elapsedTimeInSecs * 100) / 100;

s.appendFile(LOG_FILE, timeRounded + "," + gbRounded + os.EOL, () => {}); // 請求-確認(rèn)

上面這段代碼可以用來調(diào)試內(nèi)存泄漏的情況下，堆內(nèi)存隨著時間變化而增長。你可以使用一些分析工具來解析原生csv數(shù)據(jù)以實(shí)現(xiàn)一個比較漂亮的可視化。

如果你只是趕著看看數(shù)據(jù)的情況，直接用excel也可以，如下圖：

在限制為4.1GB的情況下，你可以看到內(nèi)存的使用率在短時間內(nèi)呈線性增長。內(nèi)存的消耗在持續(xù)的增長并沒有變得平緩，這個說明了某個地方存在內(nèi)存泄漏。在我們調(diào)試這類問題的時候，我們要尋找在分配在老世代結(jié)束時的那部分代碼。

對象如果再在垃圾回收時幸存下來，就可能會一直存在，直到進(jìn)程終止。

使用這段內(nèi)存泄漏檢測代碼更具復(fù)用性的一種方法是將其包裝在自己的時間間隔內(nèi)（因?yàn)樗槐卮嬖谟谥餮h(huán)中）。

setInterval(() => {
  const mu = process.memoryUsage();
  // # bytes / KB / MB / GB
  const gbNow = mu[field] / 1024 / 1024 / 1024;
  const gbRounded = Math.round(gbNow * 100) / 100;

  const elapsedTimeInSecs = (Date.now() - start) / 1000;
  const timeRounded = Math.round(elapsedTimeInSecs * 100) / 100;

  fs.appendFile(LOG_FILE, timeRounded + "," + gbRounded + os.EOL, () => {}); // fire-and-forget
}, TIME_INTERVAL_IN_MSEC);

要注意上面這些方法并不能直接在生產(chǎn)環(huán)境中使用，僅僅只是告訴你如何在本地環(huán)境調(diào)試內(nèi)存泄漏。在實(shí)際實(shí)現(xiàn)時還包括了自動顯示、警報(bào)和輪換日志，這樣服務(wù)器才不會耗盡磁盤空間。

跟蹤生產(chǎn)環(huán)境中的 Node.js 內(nèi)存泄漏

盡管上面的代碼在生產(chǎn)環(huán)境中不可行，但我們已經(jīng)看到了如何去調(diào)試內(nèi)存泄漏。因此，作為替代方案，可以將 Node 進(jìn)程包裹在 PM2 之類 的 守護(hù)進(jìn)程 中。

當(dāng)內(nèi)存消耗達(dá)到限制時設(shè)置重啟策略：

pm2 start index.js --max-memory-restart 8G

單位可以是 K（千字節(jié)）、M（兆字節(jié)）和 G（千兆字節(jié)）。進(jìn)程重啟大約需要 30 秒，因此通過負(fù)載均衡器配置多個節(jié)點(diǎn)以避免中斷。

另一個漂亮的工具是跨平臺的原生模塊node-memwatch，它在檢測到運(yùn)行代碼中的內(nèi)存泄漏時觸發(fā)一個事件。

const memwatch = require("memwatch");

memwatch.on("leak", function (info) {  // event emitted  console.log(info.reason);
});復(fù)制代碼

事件通過leak觸發(fā)，并且它的回調(diào)對象中有一個reason會隨著連續(xù)垃圾回收的堆增長而增長。

使用 AppSignal 的 Magic Dashboard 診斷內(nèi)存限制

AppSignal 有一個神奇的儀表板，用于監(jiān)控堆增長的垃圾收集統(tǒng)計(jì)信息。

上圖顯示請求在 14:25 左右停止了 7 分鐘，允許垃圾回收以減少內(nèi)存壓力。當(dāng)對象在舊的空間中停留太久并導(dǎo)致內(nèi)存泄漏時，儀表板也會暴露出來。

關(guān)于“Node中堆內(nèi)存分配的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

分享標(biāo)題：Node中堆內(nèi)存分配的示例分析
本文網(wǎng)址：http://chinadenli.net/article26/giosjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、App設(shè)計(jì)、服務(wù)器托管、域名注冊、標(biāo)簽優(yōu)化、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)