معدل تسرب الذاكرة

خطوات الاستخدام

1. أدخل مقدار الذاكرة المستخدمة في البداية (initialMB) بالميغابايت. هذه هي القيمة الأولية لذاكرة التطبيق قبل بدء التشغيل أو بعد إعادة تعيين. على سبيل المثال، إذا بدأ التطبيق باستخدام 50 ميغابايت، أدخل 50.

2. أدخل مقدار الذاكرة المستخدمة حالياً (currentMB) بالميغابايت. هذه هي قيمة الذاكرة بعد فترة من تشغيل التطبيق. تُقاس عادةً بعد تنفيذ عمليات متكررة أو اختبارات إجهاد. على سبيل المثال، إذا زاد الاستخدام إلى 120 ميغابايت، أدخل 120.

3. أدخل الوقت المنقضي (timeMin) بالدقائق بين القياسين. يجب أن يكون الوقت مطابقاً للفاصل الزمني بين أخذ القياسين الأول والثاني. على سبيل المثال، إذا مرت 30 دقيقة، أدخل 30.

4. تقوم الحاسبة بحساب معدل تسرب الذاكرة باستخدام الصيغة: (currentMB - initialMB) / (timeMin / 60). أي أنها تطرح الذاكرة الأولية من الحالية للحصول على الزيادة الكلية، ثم تقسم على الوقت بالساعات (لأن الناتج بالميغابايت لكل ساعة). والنتيجة هي معدل النمو في الساعة.

الأسئلة الشائعة

تسرب الذاكرة هو فشل في تحرير الذاكرة التي لم تعد هناك حاجة إليها. في اللغات المدارة مثل Java أو C#، يحدث عندما تحتفظ الكائنات بمراجع غير مقصودة بحيث لا تستطيع جامع القمامة (Garbage Collector) استعادتها. في C/C++ يحدث عندما لا يتم استدعاء free أو delete. في JavaScript، قد تسبب closures أو المؤقتات غير المقصودة تسرباً. يتراكم التسرب تدريجياً مما يؤدي إلى تدهور الأداء وانتهاء الذاكرة (OutOfMemory). من الأسباب الشائعة: تسجيل المستمعين للأحداث دون إلغائها، التخزين المؤقت غير المحدود (caches)، الكائنات الثابتة التي تحتوي على مراجع لمجموعات كبيرة، وعدم تحرير الموارد مثل الملفات أو اتصالات قاعدة البيانات. للكشف عنه، نستخدم أدوات تحليل الذاكرة مثل VisualVM, Chrome DevTools, أو Valgrind لقياس النمو بمرور الوقت.

يدوياً، يتم أخذ قياسين للذاكرة (باستخدام أدوات مثل task manager, ps, أو أدوات مدمجة) بفاصل زمني معين. الصيغة: (memory_current - memory_initial) / (time_hours). لكن القياس قد يكون غير دقيق بسبب: (1) تشغيل جمع القمامة أثناء القياس مما يغير الذاكرة. (2) وجود ذاكرة مؤقتة (temporary objects) قد تتحرر لاحقاً. (3) عدم استقرار النظام حيث تعمل تطبيقات أخرى. لذلك يُفضل أخذ متوسط عدة قياسات على فترات مختلفة وتجنب فترات النشاط العالي. أيضاً، بعض التسربات قد تكون بطيئة جداً تحتاج مراقبة ساعات. تستخدم أدوات مثل Heapshot في Xcode أو memcheck لتحديد التسرب بدقة.

نعم، هناك عدة أنواع: (1) تسرب المكتشف (Detected Leak): حيث تُفقد مراجع الكائنات ولا يمكن الوصول إليها. في C/C++ هذا واضح. في اللغات المدارة يتم اكتشافه عبر أدوات تحليل. الحل: التأكد من تحرير الموارد يدوياً أو استخدام using blocks. (2) تسرب غير مكتشف (Logical Leak): حيث تبقى الكائنات قابلة للوصول (reachable) ولكنها غير ضرورية. مثال: احتفاظ بخريطة (Map) من الكائنات دون تنظيف. الحل: استخدام WeakReferences أو التخزين المؤقت المحدود الحجم. (3) تسرب بسبب منظمات الأحداث (Event Listener Leaks): عدم إلغاء الاشتراك عند تدمير المكون. الحل: إلغاء الاشتراك في دورة الحياة المناسبة. (4) تسرب بسبب السلسلة المرجعية الدائرية (Cyclic References) في اللغات غير المُدارة. في .NET مثلاً، يمكن استخدام WeakReference. لكل نوع، هناك أدوات واستراتيجيات محددة مثل استخدام الأدوات البروفايلر، وتنفيذ نمط Dispose.

معدل 0 يعني عدم وجود زيادة في استخدام الذاكرة بين القياسين: إما أن التطبيق لا يعاني من تسرب، أو أن التسرب قد عوضه جمع القمامة في نفس الفترة. لكن الأفضل مراقبة على مدى أطول. معدل سلبي يعني أن الذاكرة انخفضت، وهو أمر طبيعي إذا حدث جمع قمامة كبير أو تحرير موارد. لكن القيمة السالبة ليست تسرباً، بل مؤشر على تحسن حالة الذاكرة. لكن يجب الحذر: إذا كان المعدل موجباً لفترة طويلة ثم صفرياً أو سالباً، فقد يكون بسبب انتظام جمع القمامة بعد بناء الكثير من الكائنات المؤقتة. التحليل الدقيق يتطلب تتبع الذاكرة في نقاط زمنية متعددة.

معدل تسرب الذاكرة

أدخل القيم

خطوات الاستخدام

أمثلة محلولة

أمثلة محسوبة

الأسئلة الشائعة

أدخل القيم

خطوات الاستخدام

حاسبات ذات صلة

1مثال 1: تطبيق خادم ويب يبدأ باستخدام 200 ميغابايت من الذاكرة. بعد تشغيله لمدة 4 ساعات (240 دقيقة)، يرتفع الاستخدام إلى 500 ميغابايت. احسب معدل تسرب الذاكرة.

أمثلة محسوبة

الأسئلة الشائعة