Event Loop، Memory Model و Async Architecture در JavaScript — آنچه واقعاً اتفاق می‌افتد

فرض کن یه دکمه داری که وقتی کاربر روش کلیک می‌کنه، یه API call می‌زنه. همزمان یه تایمر داری که هر ثانیه UI رو آپدیت می‌کنه. همزمان یه Promise هم داری که داره resolve می‌شه. JavaScript چطور تصمیم می‌گیره کدوم اول اجرا بشه؟

اگه جواب دقیق این سوال رو نمی‌دونی، این مقاله برات نوشته شده. اینجا قرار نیست فقط تعریف Event Loop رو بخونی — قراره بفهمی چطور JavaScript زیر پوسته کار می‌کنه، چطور حافظه مدیریت می‌شه، و چطور async code واقعاً اجرا می‌شه.

مشکلی که JavaScript با آن روبرو بود

JavaScript از ابتدا single-threaded طراحی شد — یعنی در هر لحظه فقط یه کار می‌تونه انجام بده. این به نظر یه محدودیت جدی می‌رسه. اگه یه network request داشتی که ۳ ثانیه طول می‌کشید، آیا باید همه چیز فریز می‌شد؟

جواب no هست — و Event Loop دلیلشه.

Event Loop — قلب تپنده JavaScript

وقتی JavaScript اجرا می‌شه، سه مکان اصلی وجود داره که باید بشناسی:

Call Stack جاییه که کد synchronous اجرا می‌شه. وقتی یه function صدا می‌زنی، روی stack می‌ره. وقتی return می‌کنه، از stack بر می‌داره.

Microtask Queue جاییه که Promise‌ها و queueMicrotask‌ها منتظر می‌مونن. این queue اولویت بالاتری داره.

Task Queue (یا Macrotask Queue) جاییه که setTimeout، setInterval و event‌های DOM منتظر می‌مونن.

قانون Event Loop ساده ولی مهمه: هر بار که Call Stack خالی می‌شه، ابتدا تمام microtask‌های موجود اجرا می‌شن، بعد یه task از task queue برداشته می‌شه، و دوباره microtask‌ها چک می‌شن.

ترتیب اجرا — یه تست واقعی

این کد رو ببین. قبل از اینکه ادامه بدی، پیش‌بینی کن خروجی چیه:


console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

خروجی: 1، 4، 3، 2

چرا؟ اول کدهای synchronous اجرا می‌شن (1 و 4). بعد از خالی شدن Call Stack، microtask queue اولویت داره (3). و در آخر task queue (2) — حتی اگه setTimeout با تاخیر صفر باشه.

یه مثال پیچیده‌تر — برای مصاحبه‌های senior

این کد یه درجه سخت‌تره:


console.log('start');

setTimeout(() => {
  console.log('timeout');
  Promise.resolve().then(() => console.log('promise inside timeout'));
}, 0);

Promise.resolve()
  .then(() => {
    console.log('promise 1');
    return Promise.resolve();
  })
  .then(() => console.log('promise 2'));

console.log('end');

خروجی: start، end، promise 1، promise 2، timeout، promise inside timeout

نکته کلیدی اینجاست: وقتی setTimeout اجرا می‌شه (یه task)، هر Promise‌ای که داخلش تعریف کنی بعد از تموم شدن اون task به microtask queue می‌ره و بلافاصله بعد از callback اجرا می‌شه. هر task که اجرا می‌شه، microtask‌هایش بلافاصله بعد از اتمام اون task اجرا می‌شن.

Memory Model — حافظه چطور کار می‌کنه

JavaScript دو فضای اصلی برای ذخیره داده داره که باید تفاوتشون رو بدونی:

Stack برای primitive‌ها (number، string، boolean) و function call‌هاست. سریعه، کوچیکه، و به روش LIFO مدیریت می‌شه. محدودیت سایز داره — stack overflow از همین جاست.

Heap برای object‌ها و آرایه‌هاست. بزرگتره، کندتره، و اینجاست که Garbage Collector کار می‌کنه.


// Stack — مقادیر primitive
let count = 5;
let name = 'Masoud';

// Heap — references
let user = { name: 'Masoud' };
let items = [1, 2, 3];

Garbage Collection — Mark and Sweep

JavaScript به صورت خودکار حافظه رو مدیریت می‌کنه. الگوریتم اصلی Mark and Sweep هست:

مرحله Mark: GC از root‌ها (global object، call stack) شروع می‌کنه و هر چیزی که reachable هست رو علامت می‌زنه.

مرحله Sweep: هر چیزی که علامت نخورده آزاد می‌شه.


let user = { name: 'Ali' }; // reachable — نگه می‌داره
user = null;                 // unreachable — GC آزاد می‌کنه

Memory Leak در React — سه الگوی رایج

با اینکه GC وجود داره، هنوز می‌شه memory leak ایجاد کرد. در React سه الگوی رایج داریم:

الگوی اول — Event Listener پاک نشده:


// ❌ اشتباه — listener هیچ‌وقت حذف نمی‌شه
useEffect(() => {
  window.addEventListener('resize', handler);
}, []);

// ✅ درست — cleanup انجام می‌شه
useEffect(() => {
  window.addEventListener('resize', handler);
  return () => window.removeEventListener('resize', handler);
}, []);

الگوی دوم — Interval پاک نشده:


useEffect(() => {
  const id = setInterval(fetchData, 1000);
  return () => clearInterval(id); // ✅ ضروریه
}, []);

الگوی سوم — Fetch روی Unmounted Component:


// ❌ مشکل: اگه component قبل از تموم شدن fetch unmount بشه،
// setResults روی یه component ناموجود صدا زده می‌شه
useEffect(() => {
  fetch('/api/search')
    .then(res => res.json())
    .then(data => setResults(data));
}, []);

// ✅ راه حل با AbortController
useEffect(() => {
  const controller = new AbortController();

  fetch('/api/search', { signal: controller.signal })
    .then(res => res.json())
    .then(data => setResults(data))
    .catch(err => {
      if (err.name === 'AbortError') return;
    });

  return () => controller.abort();
}, []);

نکته مهم: از React 18 به بعد warning مربوط به setState روی unmounted component حذف شد، ولی مشکل هنوز وجود داره. مسئولیت handle کردنش با توئه.

Promise Internals — زیر پوسته Promise

Promise یه state machine هست با سه حالت: pending، fulfilled، و rejected. قانون مهم اینه که وقتی از pending خارج شد، دیگه تغییر نمی‌کنه:


const p = new Promise((resolve, reject) => {
  resolve('ok');
  resolve('again'); // ❌ نادیده گرفته می‌شه
  reject('error');  // ❌ نادیده گرفته می‌شه
});

هر .then یه Promise جدید برمی‌گردونه — این دلیل اصلیه که chaining ممکنه:


Promise.resolve(1)
  .then(val => val + 1) // Promise جدید با value 2
  .then(val => val + 1) // Promise جدید با value 3
  .then(val => console.log(val)); // 3

async/await — sugar روی Promise

async/await در واقع همون Promise هست با syntax بهتر. این دو کاملاً معادلن:


// با Promise
function fetchUser() {
  return fetch('/api/user')
    .then(res => res.json())
    .then(data => data.name);
}

// با async/await — دقیقاً همونه
async function fetchUser() {
  const res = await fetch('/api/user');
  const data = await res.json();
  return data.name;
}

وقتی به await می‌رسی، function pause می‌شه و control برمی‌گرده به caller. بقیه کد continue می‌کنه:


async function main() {
  console.log('1');
  await Promise.resolve();
  console.log('3'); // این به microtask queue می‌ره
}

main();
console.log('2');

// Output: 1, 2, 3

Promise.all vs race vs allSettled — کِی کدوم؟

یکی از سوالات رایج مصاحبه اینه که تفاوت این‌ها رو توضیح بدی و بگی کِی کدوم رو استفاده می‌کنی:

Promise.all — همه باید موفق بشن. اگه یکی fail کنه، کل چیز reject می‌شه. مناسب وقتی نتایج به هم وابسته‌ان:


const [user, posts] = await Promise.all([
  fetchUser(),
  fetchPosts()
]);
// اگه fetchUser fail کنه → کل چیز reject می‌شه

Promise.race — اولی که تموم شد wins، چه موفق چه fail. مناسب برای timeout pattern:


const result = await Promise.race([
  fetch('/api/data'),
  new Promise((_, reject) =>
    setTimeout(() => reject(new Error('timeout')), 5000)
  )
]);

Promise.allSettled — همه اجرا می‌شن، صرف نظر از موفق یا fail بودن. مناسب وقتی می‌خوای همه request‌ها بزنی و بعد ببینی کدوم موفق شدن:


const results = await Promise.allSettled([
  fetchUser(),
  fetchPosts(),
  fetchComments()
]);

results.forEach(result => {
  if (result.status === 'fulfilled') {
    console.log(result.value);
  } else {
    console.log(result.reason);
  }
});

سناریوی واقعی — Dashboard با Widget‌های مستقل

فرض کن داری یه dashboard می‌سازی با ۴ تا widget مستقل. هر کدوم یه API call جدا دارن. اگه یکی fail کنه نباید بقیه تحت تأثیر قرار بگیرن.

یه نفر ممکنه اینطور بنویسه:


// ❌ مشکل: همه با هم منتظر می‌مونن
const results = await Promise.allSettled([
  fetchWidget1(),
  fetchWidget2(),
  fetchWidget3(),
  fetchWidget4(),
]);
// UI تا وقتی کندترین API جواب نده، هیچ‌چیز نشون نمی‌ده

مشکل اینجاست که کاربر باید منتظر کندترین API بمونه. اگه fetchWidget1 در 100ms جواب بده و fetchWidget4 در 3 ثانیه، کاربر ۳ ثانیه صفر می‌بینه.

راه حل senior-level — Progressive Loading:


const [widgets, setWidgets] = useState({
  user:     { status: 'loading', data: null },
  posts:    { status: 'loading', data: null },
  comments: { status: 'loading', data: null },
  stats:    { status: 'loading', data: null },
});

useEffect(() => {
  // هر fetch مستقله — منتظر بقیه نمی‌مونه
  fetchUser()
    .then(data => setWidgets(prev => ({
      ...prev,
      user: { status: 'fulfilled', data }
    })))
    .catch(() => setWidgets(prev => ({
      ...prev,
      user: { status: 'rejected', data: null }
    })));

  fetchPosts()
    .then(data => setWidgets(prev => ({
      ...prev,
      posts: { status: 'fulfilled', data }
    })))
    .catch(() => setWidgets(prev => ({
      ...prev,
      posts: { status: 'rejected', data: null }
    })));

  // همینطور برای بقیه...
}, []);

// هر widget مستقلاً render می‌شه
function Widget({ status, data, fallback }) {
  if (status === 'loading') return Loading...;
  if (status === 'rejected') return {fallback};
  return {data};
}

این pattern اسم داره: Progressive Loading. کاربر به محض آماده شدن هر widget، اون رو می‌بینه — نه اینکه منتظر همه بمونه.

تحلیل Performance

این‌ها مفاهیمی نیستن که فقط روی کاغذ مهم باشن. تأثیر مستقیم روی performance دارن:

وقتی microtask queue پر بشه (مثلاً با Promise chain‌های طولانی)، main thread block می‌شه و rendering به تأخیر می‌افته. این یعنی animation‌ها drop می‌کنن و UI به نظر laggy می‌رسه.

memory leak‌ها اول کند می‌شن، بعد crash می‌کنن. با Chrome DevTools Memory tab می‌تونی heap snapshot بگیری و ببینی کدوم object‌ها reachable هستن ولی نباید باشن.

با Promise.allSettled به جای fetching مستقل، می‌تونی Time to Interactive (TTI) رو تا ۳ برابر بدتر کنی — چون کاربر باید منتظر کندترین API بمونه.

تأیید با Chrome DevTools

برای دیدن Event Loop در عمل، Performance tab رو باز کن و یه recording بگیر. هر task رو می‌تونی ببینی — طول، نوع، و اینکه چقدر main thread رو گرفته.

برای memory leak، به Memory tab برو. یه heap snapshot بگیر، یه action انجام بده، دوباره snapshot بگیر. اگه object‌هایی می‌بینی که باید garbage collect می‌شدن ولی هنوز هستن، احتمالاً leak داری.

اشتباهات رایج

اشتباه اول — فکر کردن که setTimeout(fn, 0) فوری اجراست: setTimeout همیشه به task queue می‌ره، حتی با تاخیر صفر. یعنی حتماً بعد از همه microtask‌های موجود اجرا می‌شه.

اشتباه دوم — استفاده از Promise.all وقتی عملیات‌ها مستقلن: اگه widget‌ها یا data source‌هات به هم وابسته نیستن، Promise.allSettled با fetching مستقل UX بهتری می‌ده.

اشتباه سوم — فراموش کردن cleanup در useEffect: هر subscription، event listener، یا interval که داخل useEffect می‌سازی باید cleanup داشته باشه.

اشتباه چهارم — اشتباه گرفتن memory leak با crash: memory leak معمولاً آروم آروم اتفاق می‌افته. برنامه اول کند می‌شه، بعد tab crash می‌کنه. منتظر crash نمون — با DevTools چک کن.

ملاحظات پروژه واقعی

توی production، event loop management معمولاً از طریق ابزارهایی مثل Web Workers انجام می‌شه. اگه computation سنگینی داری که main thread رو block می‌کنه، Worker مناسب‌تره از setTimeout/Promise.

برای dashboard‌ها و data-heavy interfaces، pattern Progressive Loading که بالا گفتیم استاندارد industry هست. React Query و SWR این کار رو automatically می‌کنن — ولی مهمه که بدونی زیرش چی اتفاق می‌افته.

در مصاحبه‌های senior، فقط دانستن API کافی نیست. باید بتونی توضیح بدی چرا یه pattern رو انتخاب می‌کنی و trade-off‌هاش چیه. مثلاً: "از Promise.allSettled استفاده کردم چون widget‌ها مستقلن و نمی‌خوام fail شدن یکی بقیه رو block کنه."

جمع‌بندی

JavaScript single-threaded هست، ولی Event Loop این محدودیت رو با مدیریت صف‌های مجزا (microtask و task queue) حل می‌کنه. Microtask‌ها (Promise) همیشه قبل از task‌ها (setTimeout) اجرا می‌شن.

Memory management در JavaScript خودکاره، ولی نه کامل. Event listener‌ها، interval‌ها، و async operation‌های cleanup نشده می‌تونن به memory leak تبدیل بشن.

Promise.all، race، و allSettled هر کدوم برای سناریوی خاصی طراحی شدن. انتخاب اشتباه مستقیماً روی UX تأثیر می‌ذاره.

وقتی این مفاهیم رو بفهمی، نه فقط code بهتری می‌نویسی — بلکه می‌تونی درباره performance، architecture و trade-off‌ها حرف بزنی. این تفاوت یه developer با یه مهندسه.