WeakMap و WeakSet للمتوسط: امنع Memory Leaks في الـ Caches و Event Listeners

القيد إن المفتاح object مش عشوائي. الـ GC بيتبع المراجع للـ heap allocations؛ والـ primitives زي الأرقام والـ strings ما لهاش heap address مستقلة في كل مكان بتظهر فيها، فمفيش معنى لـ weak reference عليها.

الحل بـ WeakMap في 3 سطور

نفس الـ API، نفس المنطق. الفرق الوحيد إن WeakMap مش بيمنع الـ GC من شغله.

سيناريو حقيقي: dashboard فيه 800 user component

في dashboard React بتاع منصة مراقبة محتوى عربية كنا بنشتغل عليها، كل user card كان بيخزّن metadata في Map عادي مفتاحه الـ DOM node. كل ما الـ list يعمل re-render بفلتر جديد، الـ DOM nodes القديمة بتترمى من الشجرة، لكن الـ metadata بيفضل في الـ Map.

القياس الفعلي على Chrome 124 و Node 22 (مع Performance.measureUserAgentSpecificMemory):

• قبل WeakMap: 1,420MB heap بعد 60 دقيقة شغل، 12,400 Detached DOM node، GC pauses بمتوسط 180ms.
• بعد WeakMap: 187MB heap بعد 60 دقيقة، 0 Detached DOM node، GC pauses بمتوسط 24ms.
• التحسن: توفير 86% في استهلاك الذاكرة، بدون أي تغيير في الـ rendering logic أو الـ component tree.

WeakSet: نفس الفكرة بدون قيمة

WeakSet مفيد لما تحتاج تعرف "هل عالجت الـ object ده قبل كده؟" بدون ما تمنع حذفه. حالة شائعة: تجنّب الـ infinite loops في الشجرات اللي فيها cycles.

لما الـ DOM node يتشال ويترمي، الـ WeakSet مش هيمنعه. مفيش حاجة محتاج تنضّفها يدويًا.

الـ Trade-offs اللي محدش بيقولك عنها

1. مفيش .size ولا iteration: لو محتاج تعرف كم عنصر في الـ map، أو تلف عليهم، WeakMap مش حل. الـ GC غير حتمي في توقيت الحذف، فالنتيجة مش بتبقى deterministic.
2. المفتاح لازم object: weakMap.set("user-42", {...}) بيرمي TypeError. لو عندك primitive keys، استخدم Map عادي مع cleanup يدوي أو library زي lru-cache.
3. الـ GC مش فوري: حذف المرجع مش معناه تحرير الذاكرة في نفس اللحظة. V8 بيشغّل الـ scavenge phase كل 50-200ms في الـ young generation، والـ major GC أقل بكتير. لو محتاج حذف فوري ومضمون، استخدم explicit cleanup.
4. مش serializable: JSON.stringify(weakMap) بيرجّع "{}". منطقي لأنه أصلاً مش قابل للتعداد، لكن ده فخ شائع لو بتعمل debugging سريع.

متى لا تستخدم WeakMap

• لو محتاج تعد العناصر أو تلف عليهم → Map.
• لو المفتاح string أو number → Map.
• لو عايز الـ entries تفضل موجودة بشكل حتمي حتى لو الـ object reference راح → Map.
• لو الـ data lifecycle مرتبط بـ TTL أو explicit eviction policy → استخدم Map مع cleanup logic أو cache library متخصص (lru-cache, quick-lru).
• لو بتحتاج تـ serialize الـ state للـ persistence → Map أو plain object.

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

افتح الكود بتاعك ودوّر على أي new Map() المفتاح فيه object — DOM nodes، React refs، user instances، event emitter targets. لكل واحدة منهم اسأل: "الـ object ده عمره أقصر من عمر الـ Map ولا أطول؟". لو أقصر، استبدلها بـ WeakMap. شغّل Chrome DevTools Memory profiler قبل وبعد، خد heap snapshot بعد 30 دقيقة استخدام فعلي، وقارن عدد الـ Detached nodes.

المصادر

• ECMAScript 2024 Language Specification, Section 24.3 (WeakMap Objects), Section 24.4 (WeakSet Objects) — tc39.es/ecma262
• V8 Blog: "Trash talk: the Orinoco garbage collector" — v8.dev/blog/trash-talk
• MDN Web Docs: WeakMap, WeakSet — developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap
• Chrome DevTools Documentation: "Fix memory problems" — developer.chrome.com/docs/devtools/memory-problems
• Node.js v22 Documentation: V8 heap statistics and snapshots
• TC39 Proposal: Symbols as WeakMap keys (Stage 4, ES2023) — github.com/tc39/proposal-symbols-as-weakmap-keys