دفتر حافظه JSON: رشته‌ها، اشیا و آرایه‌های بزرگ واقعاً چه هزینه‌ای دارند

جمع‌بندی: اول با process.memoryUsage خط پایه بگیرید و متن و گراف شیء را به‌عنوان دو افزایش جدا ثبت کنید، سپس پیش از هر چیز یک کپی کامل را حذف کنید — بدون JSON.parse(JSON.stringify(x))، بدون پیچیدن سند خام در reactive. بعد ارجاع‌های بلندعمر را قطع کنید و جریان را آخر در نظر بگیرید: منحنی حافظه تختش فقط وقتی ارزش از دست دادن دسترسی تصادفی را دارد که فایل جا نمی‌شود یا فقط چند فیلد می‌خواهید.

یک سند JSON ده مگابایتی پس از JSON.parse می‌تواند در heap به ۳۰ تا ۵۰ مگابایت تبدیل شود، و اوج گذرا بالاتر هم می‌رود. بدون این حساب، «بهینه‌سازی» حدس است.

۱. متن و گراف شیء دو دفتر متفاوت‌اند

روی دیسک و در بدنه درخواست، JSON دنباله‌ای از بایت است. به‌محض ورود به حافظه، دو چیز می‌شود: یک رشته، و یک گراف شیء ساخته‌شده از اشیا، آرایه‌ها، عددها و بولی‌ها. جدا نگه داشتن این دو دفتر تنها راه توضیح این است که چرا فایل ۱۰ مگابایتی می‌تواند فرایندی را به مصرف ۸۰ مگابایت برساند.

این ضرایب مرجع مرتبه بزرگی‌اند که به نسخه V8، فشرده‌سازی اشاره‌گر، تعداد فیلد و محتوای رشته بستگی دارند. جدول یک نکته را می‌گوید: اندازه گراف شیء بر اساس «تعداد گره × سربار هر گره» است، نه تعداد بایت‌های متن.

۲. رشته‌ها: کم‌برآوردشده‌ترین ردیف

یک رشته V8 آرایه نویسه لخت نیست. سرآیند شیء حمل می‌کند (اشاره‌گر map، فیلد هش و طول) که روی بیلد معمول ۶۴ بیتی با فشرده‌سازی اشاره‌گر حدود یک دوجین بایت هزینه دارد، پیش از هر نویسه. نویسه‌ها به یکی از دو شکل ذخیره می‌شوند:

• رشته‌های یک‌بایتی برای نویسه‌های بازه Latin-1: ۱ بایت به ازای هر نویسه؛
• رشته‌های دوبایتی وقتی محتوا نویسه‌های CJK، ایموجی یا چیزی بیرون از Latin-1 دارد: ۲ بایت به ازای هر نویسه.

یک نویسه چینی در فایل UTF-8 سه بایت اشغال می‌کند اما در رشته دوبایتی ۲ بایت به ازای هر نویسه، به‌علاوه سرآیند. اندازه متن و اندازه heap یک اندازه‌گیری نیستند و همیشه در یک جهت حرکت نمی‌کنند.

سه جزئیات مستقیماً برای کار با JSON مهم‌اند:

1. برش‌ها والد را زنده نگه می‌دارند. V8 زیررشته‌های بلندتر را به‌صورت SlicedString نمایش می‌دهد که ارجاع والد به‌علاوه offset و طول را ذخیره می‌کند. ۲۰۰ نویسه بریده‌شده از لاگ ۸۰ مگابایتی را ذخیره کنید و کل ۸۰ مگابایت تا آزاد شدن آن برش قابل دسترس می‌ماند.
2. الحاق ConsString می‌سازد. += مکرر روی رشته‌های بزرگ درختی از قطعه‌ها می‌سازد که فقط وقتی نویسه‌ها واقعاً خوانده شوند در حافظه پیوسته تخت می‌شود. ده هزار بار الحاق و سپس یک بار خواندن، در همان لحظه جهش تخصیص بزرگی تولید می‌کند.
3. مقادیر تکراری خودکار مشترک نمی‌شوند. ده هزار رکورد حاوی "status": "paid" معمولاً ده هزار شیء رشته مستقل می‌گیرند؛ پارسر آن‌ها را به یک ثابت اشاره نمی‌دهد. برای ذخیره این هزینه باید خودتان رشته‌های پرتکرار را به enum یا عدد نگاشت کنید.

وقتی باید برشی کوتاه را مدت طولانی نگه دارید، آن را به رشته مستقل تبدیل و اصلی را آزاد کنید:

复制// Bad: the slice references the whole document, so logText cannot be collected
const summary = logText.slice(0, 200);

// Good: create an independent string, then release logText
const summaryCopy = Buffer.from(summary, 'utf8').toString('utf8');

۳. اشیا: هر کلید یک جایگاه اشغال می‌کند

یک شیء ساده حداقل سه چیز دارد: اشاره‌گری به کلاس پنهانش (map)، اشاره‌گری به انبار ویژگی و اشاره‌گری به انبار عنصرش. با فشرده‌سازی اشاره‌گر هر اشاره‌گر ۴ بایت است و سرآیند شیء heap بیشتر اضافه می‌کند، پس حتی شیء خالی حدود شانزده تا بیست‌وچند بایت هزینه دارد. روی بیلد ۶۴ بیتی بدون فشرده‌سازی اشاره‌گر، دو برابرش کنید.

ویژگی‌های نام‌دار در یکی از دو جا می‌نشینند:

• ویژگی‌های درون‌شیء: جایگاه‌هایی که مستقیماً بعد از سرآیند شیء چیده می‌شوند و سریع‌ترین دسترسی را می‌دهند؛
• یک PropertyArray: وقتی جایگاه‌های درون‌شیء تمام شوند، ویژگی‌ها به آرایه جداگانه می‌روند و شیء اشاره‌گری به آن نگه می‌دارد.

هر جایگاه ۴ یا ۸ بایت است و رشته کلید جدا حساب می‌شود. همین دلیل است که نام‌های فیلد بلند در صدها هزار رکورد هزینه واقعی می‌شوند، نه فقط مسئله زیبایی.

خبر خوب این است که کلاس‌های پنهان مشترک‌اند: یک میلیون شیء با همان کلیدها در همان ترتیب، یک map مشترک دارند نه کپی اطلاعات ساختاری. خبر بد این است که این الگوها آن اشتراک را می‌شکنند یا شیء را به نمایش گران‌تری می‌برند:

• برخی رکوردها فیلد remark دارند و برخی نه، که دو شکل و یک بررسی شکل اضافه در هر دسترسی تولید می‌کند؛
• ترتیب درج متفاوت می‌تواند شکل‌های متفاوت تولید کند؛
• تعداد ویژگی بسیار زیاد (فراتر از حدود هزار) یا عملیات delete مکرر شیء را به حالت dictionary می‌برد که هر ویژگی یک ورودی جدول هش هم حمل می‌کند؛
• Object.create(null) از تولد در حالت dictionary است. جدول جست‌وجوی خوبی است و انتخاب بدی برای رکورد با schema ثابت که در حلقه داغ دسترسی می‌شود.

یک باور غلط رایج شایسته اصلاح است: JSON کلید تکراری را مجاز می‌داند و {"a":1,"a":2} سند معتبری است که نتیجه‌اش a === 2 است. شیء نهایی یک مقدار نگه می‌دارد، اما پارسر همچنان هر occurrence را پویش و انتساب می‌کند. کلیدهای تکراری حافظه ذخیره نمی‌کنند؛ فقط زمان تجزیه هزینه دارند.

۴. آرایه‌ها و عددها: انواع element عرض را تعیین می‌کنند

V8 چند «نوع element» برای آرایه‌ها ردیابی می‌کند و هر یک عرض متفاوت به ازای هر جایگاه دارد:

دو قاعده ارزش حفظ کردن دارند:

اول، انواع element فقط تنزل می‌کنند. آرایه‌ای که با عددهای صحیح کوچک شروع می‌شود، به‌محض درج 0.5 آرایه double می‌شود و با درج رشته، آرایه element عمومی. هرگز خودکار بازیابی نمی‌شود؛ باید آرایه جدید بسازید.

دوم، جای نشستن عدد JSON به مقدارش بستگی دارد. عددهای صحیح در بازه Smi (تقریباً مثبت یا منفی ۱.۰۷ میلیارد) مستقیماً به‌صورت Smi ذخیره می‌شوند و یک جایگاه اشاره‌گر اشغال می‌کنند. عددهای اعشاری یا توان‌دار، یا مقادیر بیرون از آن بازه، HeapNumber حدود ۱۶ بایتی تخصیص می‌دهند با اشاره‌گری به آن در آرایه. پس [1, 2, 3] و [0.1, 0.2, 0.3] نه فقط در مقدار بلکه در «یک جایگاه ۴ بایتی» در برابر «یک جایگاه ۸ بایتی به‌علاوه شیء heap» تفاوت دارند.

این ریشه مشکل دقت شناسه عدد صحیح بزرگ هم هست: فراتر از بازه صحیح امن، عددهای JSON به‌عنوان double رفتار می‌شوند و رقم‌های کم‌ارزش صرفاً ناپدید می‌شوند. آرایه‌های JSON به‌صورت packed و بدون حفره می‌رسند، پس پس از تجزیه عناصر را delete نکنید؛ کل آرایه را به نمایش گران‌تری می‌راند.

۵. اوج تجزیه و سریالایز: لحظه‌ای که فرایند واقعاً می‌میرد

حافظه حالت پایدار یک دفتر است؛ اوج دفتر دیگر. هنگام اجرای JSON.parse(text)، فرایند سه چیز را هم‌زمان نگه می‌دارد:

1. رشته ورودی text؛
2. گراف شیئی که ساخته می‌شود و هنوز کامل نیست؛
3. ساختارهای موقت خود پارسر.

اوج تجزیه تقریباً «متن + گراف شیء + سربار موقت» است. پس از تجزیه، اگر text همچنان توسط متغیری، closure‌ای، کش سطح ماژول یا store reactive ارجاع شود، آن حافظه متن هرگز برنمی‌گردد.

سریالایز هم اوج دارد. JSON.stringify(data) گراف شیء کامل را هنگام ساخت رشته خروجی نگه می‌دارد، با بافرهای الحاق در میانه. وقتی خروجی به محدودیت طول رشته V8 (حدود ۵۰۰ میلیون نویسه) نزدیک می‌شود، RangeError می‌اندازد؛ این شکست معمولاً در اسکریپت‌هایی ظاهر می‌شود که کل پایگاه‌داده را به‌صورت یک سند JSON صادر می‌کنند.

گران‌ترین الگوی رایج از سریالایز به‌عنوان شبیه‌سازی عمیق استفاده می‌کند:

复制// Peak is roughly: original object graph + temporary text + new object graph
const safeCopy = JSON.parse(JSON.stringify(bigData));

آن یک خط همان داده را سه بار ذخیره می‌کند. برای کار فقط-خواندنی، ارجاع بدهید. وقتی جداسازی واقعاً لازم است، از structuredClone استفاده کنید و بپذیرید که آن هم کل گراف شیء را بازمی‌سازد.

۶. اندازه‌گیری با process.memoryUsage

در Node، process.memoryUsage() پنج عدد را یکجا برمی‌گرداند: rss (حافظه فیزیکی مصرفی فرایند)، heapTotal، heapUsed (heap JS مصرفی)، external (حافظه نگه‌داشته‌شده توسط اشیای C++) و arrayBuffers (حافظه ArrayBuffer و Buffer). هنگام مطالعه مدیریت JSON، heapUsed لنز درست برای گراف شیء است و rss می‌گوید کل فرایند از کنترل خارج شده یا نه.

اسکریپت اندازه‌گیری سه انضباط می‌خواهد: اول global.gc() صدا بزنید، مرحله‌ای نمونه بگیرید و هر بار یک متغیر را تغییر دهید. این اسکریپت افزایش‌های «خواندن متن» و «تجزیه به شیء» را جدا ثبت می‌کند:

复制// Run: node --expose-gc measure-json-memory.mjs
import { readFileSync } from 'node:fs';

global.gc();
const baseline = process.memoryUsage().heapUsed;

const text = readFileSync('big.json', 'utf8');
const afterRead = process.memoryUsage().heapUsed;

const data = JSON.parse(text);
const afterParse = process.memoryUsage().heapUsed;

console.log({
  textOnHeap: afterRead - baseline,
  graphOnHeap: afterParse - afterRead,
  parsePeak: afterParse - baseline,
});

چند تله:

• --expose-gc باید صریح فعال شود؛ وگرنه global.gc وجود ندارد؛
• heapUsed فقط heap JS را پوشش می‌دهد. Bufferهای خواندن فایل زیر external و arrayBuffers زندگی می‌کنند، پس یک عدد را برای توضیح همه‌چیز استفاده نکنید؛
• بین نمونه‌ها شیء بزرگ را console.log نکنید؛ ارجاع موقت را زنده نگه می‌دارد؛
• اجرای اول شامل گرم‌شدن JIT و کامپایل تنبل است. دست‌کم سه دور اجرا کنید و میانه را بگیرید؛
• برای مقایسه در مرورگر، heap snapshot در پنل Memory ابزار توسعه بگیرید و Retained Size را بخوانید نه اینکه به دندانه اره‌ای Allocation Timeline زل بزنید.

بدون این خط پایه، ادعاهایی مانند «روی آوردن به جریان حلش می‌کند» یا «کش سریع‌ترش می‌کند» فقط احساس‌اند.

۷. جریان اوج حافظه می‌خرد، نه زمان کل

معامله در تجزیه جریانی صریح است: دسترسی تصادفی در ازای حافظه‌ای که دیگر با حجم فایل مقیاس نمی‌گیرد.

复制import { createReadStream } from 'node:fs';
import { parser } from 'stream-json';
import { pick } from 'stream-json/filters/Pick';
import { streamArray } from 'stream-json/streamers/StreamArray';

const pipeline = createReadStream('huge.json')
  .pipe(parser())
  .pipe(pick({ filter: 'items' }))
  .pipe(streamArray());

for await (const { value } of pipeline) {
  handleItem(value);
}

این کد هرگز درخت کامل نمی‌سازد، پس منحنی حافظه تخت می‌ماند. هزینه‌ها هم واقعی‌اند: نمی‌توانید برای فیلد ردشده برگردید، تجمیع‌های کلی سخت می‌شوند، بازیابی خطا مسئولیت شماست، و پویش نویسه‌به‌نویسه JS خالص معمولاً یک مرتبه بزرگی کندتر از JSON.parse بومی است.

تصمیم «آیا فایل از ۱۰ مگابایت گذشت» نیست. دو پرسش بپرسید: آیا پس از تجزیه بیشتر فیلدها را لازم دارم؟ آیا با دسترسی ترتیبی می‌توانم زندگی کنم؟ اگر هر دو پاسخ بله است، تجزیه کامل درست است و تلاش شما متعلق به کاهش کپی و رندر است. اگر هر یک نه است، جریان را در نظر بگیرید. برای راهبرد کامل لایه‌ای، تجزیه، رندر و جریان دادن JSON بزرگ را ببینید.

۸. کپی کمتر، آزادسازی زودتر

در کار حافظه، حذف یک کپی کامل غالباً از تعویض پارسر ارزشمندتر است:

• برای کار فقط-خواندنی، ارجاع بدهید. «برای امنیت» شبیه‌سازی عمیق نکنید، به‌ویژه با JSON.parse(JSON.stringify(x))؛
• سند خام را در سیستم reactive نپیچید. reactive در Vue کل گراف شیء را بازگشتی proxy می‌کند و لایه proxy هزینه حافظه خودش را دارد؛
• داده مشتق را جدا محاسبه و کش کنید. اگر فهرست فقط id، title و status می‌خواهد، رکوردهای کامل را در store نگذارید؛
• رشته‌های پرتکرار را نرمال کنید. مقادیری مانند "paid" و "pending" را به enum عددی نگاشت کنید تا هم شیء رشته و هم هزینه مقایسه ذخیره شود؛
• ارجاع‌های بلندعمر را قطع کنید. اشیای بزرگ را پس از پایان null کنید، کش‌ها را پاک کنید و callbackها را لغو ثبت کنید تا closureها آن‌ها را به صفحه بعد نبرند؛
• هزینه کپی Worker را حساب کنید. postMessage به‌صورت پیش‌فرض از کلون ساختاری استفاده می‌کند؛ فرستادن گراف شیء ۵۰ مگابایتی به رشته اصلی کپی دوم می‌سازد. هر جا ممکن است خلاصه برگردانید.

نیمه دیگر دفتر اندازه در فشرده‌سازی JSON را به ترتیب اشتباه انجام ندهید زندگی می‌کند: بایت‌های دیسک و بایت‌های سیم حساب متفاوتی از گراف شیء در heap هستند و هیچ درصد واحدی هر دو را توضیح نمی‌دهد. برای رفتار ویرایشگرها و ابزارهای CLI با حافظه، ویرایشگرها، ابزارهای خط فرمان و خودکارسازی را ببینید.

۹. چک‌لیست

چرا حافظه پس از JSON.parse سه یا چهار برابر رشد می‌کند؟

چون متن فقط ورودی است؛ محصول تجزیه یک گراف شیء است. هر شیء سرآیند دارد، هر ویژگی جایگاه دارد و هر رشته سرآیند خودش را. با گره‌های کافی، سربار کل از تعداد بایت متن بیشتر می‌شود. ضریب به شکل داده بستگی دارد و آرایه‌های شیء مسطح با اسناد عمیقاً تودرتو بسیار متفاوت‌اند.

فایل JSON ده مگابایتی را کامل تجزیه کنم یا جریانی؟

اول هدف را ببینید. اگر به دسترسی تصادفی و بیشتر فیلدها نیاز دارید و فایل در حافظه جا می‌شود، JSON.parse کامل استفاده کنید. اگر فقط چند فیلد لازم دارید یا فایل جا نمی‌شود، جریانی‌اش کنید. ۱۰ مگابایت مرز نیست؛ جریان معمولاً جایی بالاتر از ۱۰۰ مگابایت الزامی می‌شود.

چرا process.memoryUsage().heapUsed با پایش سیستم نمی‌خواند؟

heapUsed فقط بخش مصرفی heap JS را پوشش می‌دهد، بدون external، arrayBuffers و code space. پایش سیستم rss را گزارش می‌کند که اندازه‌گیری متفاوتی است. heapUsed و rss را با هم ردیابی کنید؛ شکاف بزرگ به Bufferها و اشیای بومی اشاره می‌کند.

آیا JSON.parse(JSON.stringify(x)) شبیه‌سازی عمیق امنی است؟

نه. گراف اصلی، متن موقت و گراف جدید را هم‌زمان نگه می‌دارد، پس اوج تقریباً سه برابر حالت پایدار است، و undefined، تابع‌ها و معناشناسی Date را می‌اندازد. برای کار فقط-خواندنی ارجاع بدهید؛ وقتی جداسازی لازم است از structuredClone استفاده کنید و همان هزینه بازسازی را بپذیرید.