الـ Event Loop في جافاسكريبت: ليه Promise بيسبق setTimeout وليه سطر واحد بيجمّد سيرفرك

console.log("1 sync");

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

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

console.log("4 sync");

المخرج مش بترتيب السطور، بيطلع كده:

السبب بالتفاصيل: أول console.log والأخير متزامنين، فبيتنفّذوا فورًا على الـ Call Stack. الـ setTimeout بيروح لطابور المهام الكبيرة حتى لو التأخير صفر. الـ Promise.then بيروح لطابور المهام الدقيقة. لما الكود المتزامن يخلص، الـ Event Loop بيفرّغ المهام الدقيقة الأول، فيطلع "3 promise". بعدها بس بياخد مهمة كبيرة، فيطلع "2 timeout".

يعني setTimeout(fn, 0) مش معناه "نفّذ حالًا". معناه "نفّذ في أقرب دورة مهمة كبيرة، بعد كل المهام الدقيقة". دي نقطة بتوقّع ناس كتير في bugs بترتيب التحديثات.

الخطر الحقيقي: سطر واحد بيجمّد السيرفر كله

بما إن كل ده بيحصل على خيط واحد، أي كود متزامن ثقيل بيوقف الـ Event Loop نفسه. ووقتها مفيش طلب تاني بيتخدم.

سيناريو واقعي: عندك سيرفر Node بيخدم 4800 طلب/ثانية، متوسط زمن الاستجابة (p95) حوالي 12 مللي ثانية. أضفت مسار واحد بيعمل عملية متزامنة ثقيلة (تحليل JSON ضخم أو حلقة حسابية) بتاخد 300 مللي ثانية CPU:

النتيجة اللي بتحصل فعلًا: طول الـ 300 مللي ثانية دي، الـ Event Loop واقف. كل الطلبات التانية — حتى المسارات الخفيفة — بتستنى في الطابور. الـ p95 قفز من 12 مللي ثانية لأكتر من 310 مللي ثانية، والـ throughput الكلي وقع لأن كل طلب تقيل بيسدّ الطريق قدّام العشرات.

الحل مش تعقيد: نقّل الشغل التقيل بره الخيط الرئيسي. استخدم worker_threads للحسابات، أو قسّم الشغل على دفعات وارجّع التحكم للـ Event Loop بينها:

بعد النقل للـ worker، الخيط الرئيسي فضل يخدم الطلبات الخفيفة على 12 مللي ثانية زي ما هو، والتقرير التقيل اتحسب في خيط تاني من غير ما يجمّد حد.

المقايضات (trade-offs)

• worker_threads: بتكسب إنك محبستش الـ Event Loop. بتخسر إن كل worker بياخد ذاكرة إضافية (عادةً 5–10MB لكل واحد) وفيه تكلفة نقل بيانات بينه وبين الخيط الرئيسي. مناسب للشغل الـ CPU-bound، مش لكل طلب.
• تقسيم الشغل على دفعات: أبسط من الـ workers ومفيهوش تكلفة ذاكرة، لكن بيطوّل الزمن الكلي للعملية شوية لأنك بتوقفها وترجعها.
• الاعتماد على ترتيب المهام الدقيقة: بيديك تحكم دقيق، لكن لو حطّيت microtasks بتولّد microtasks في حلقة، ممكن تجوّع طابور المهام الكبيرة وتمنع الـ I/O من الاشتغال أصلًا.

متى لا تشغل بالك بده

لو التطبيق بتاعك سكربت صغير بيتنفّذ ويخلص، أو موقع فيه تفاعلات خفيفة، الموضوع ده مش أولوية. المشكلة بتظهر بس لما يكون عندك عمل متزامن تقيل جوّه بيئة بتخدم كذا طلب في نفس الوقت (سيرفر) أو واجهة لازم تفضل سلسة (60 إطار/ثانية). غير كده، اكتب كودك عادي ومتقلقش من ترتيب الـ microtasks.

الخطوة التالية

افتح أثقل مسار في سيرفرك، وحُط قبله وبعده const t = process.hrtime.bigint() واطبع الفرق. لو لقيت دالة متزامنة واحدة بتاخد أكتر من 50 مللي ثانية على الخيط الرئيسي، دي مرشّحة تتنقل لـ worker_threads. جرّب وقارن الـ p95 قبل وبعد.

المصادر

• MDN Web Docs — The event loop (شرح Call Stack والطوابير).
• Node.js Docs — The Node.js Event Loop, Timers, and process.nextTick() (مراحل libuv وترتيب التنفيذ).
• Jake Archibald — Tasks, microtasks, queues and schedules (الفرق بين المهام الدقيقة والكبيرة).
• WHATWG HTML Standard — Event loops (التعريف المعياري الرسمي).
• Node.js Docs — worker_threads (نقل الشغل التقيل بره الخيط الرئيسي).