تسرب الذاكرة

في علم الحاسوب ، يُعدّ تسرب الذاكرة نوعًا من أنواع تسرب الموارد ، ويحدث عندما يُدير برنامج الحاسوب تخصيصات الذاكرة بشكل خاطئ ^{[ 1 ]} بحيث لا يتم تحرير الذاكرة التي لم تعد مطلوبة. وقد يحدث تسرب الذاكرة أيضًا عندما يتم تخزين كائن في الذاكرة ولكن لا يمكن الوصول إليه من قِبل الكود قيد التشغيل (أي ذاكرة غير قابلة للوصول ). ^{[ 2 ]} تتشابه أعراض تسرب الذاكرة مع أعراض عدد من المشكلات الأخرى، ولا يمكن تشخيصها عمومًا إلا من قِبل مبرمج لديه إمكانية الوصول إلى شفرة المصدر للبرنامج.

ومن المفاهيم ذات الصلة "تسرب المساحة"، وهو عندما يستهلك البرنامج ذاكرة زائدة ولكنه يحررها في النهاية. ^{[ 3 ]}

نظراً لقدرتها على استنفاد ذاكرة النظام المتاحة أثناء تشغيل التطبيق، فإن تسريبات الذاكرة غالباً ما تكون سبباً أو عاملاً مساهماً في تقادم البرامج .

وتشمل التسريبات الأكثر خطورة تلك التي:

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

تُعدّ تسريبات الذاكرة خطأً شائعًا في البرمجة، خاصةً عند استخدام لغات تفتقر إلى خاصية جمع البيانات المهملة التلقائية ، مثل لغتي C و C++ . عادةً ما يحدث تسريب الذاكرة نتيجةً لعدم إمكانية الوصول إلى جزء من الذاكرة المُخصصة ديناميكيًا . وقد أدّى انتشار أخطاء تسريب الذاكرة إلى تطوير العديد من أدوات تصحيح الأخطاء للكشف عن الذاكرة غير القابلة للوصول. ومن أشهر أدوات تصحيح أخطاء الذاكرة لبرامج C وC++: BoundsChecker و Deleaker وMemory Validator و IBM Rational Purify و Valgrind و Parasoft Insure++ و Dr. Memory و memwatch . يُمكن إضافة خاصية جمع البيانات المهملة "المحافظة" إلى أي لغة برمجة تفتقر إليها كميزة مُدمجة، وتتوفر مكتبات لهذا الغرض لبرامج C وC++. يكتشف جامع البيانات المهملة المحافظ معظم الذاكرة غير القابلة للوصول ويستعيدها، ولكن ليس كلها.

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

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

تُعدّ الأنظمة المتاحة للعامة، مثل خوادم الويب أو أجهزة التوجيه، عرضةً لهجمات حجب الخدمة إذا اكتشف المهاجم سلسلة من العمليات التي يمكن أن تُسبب تسريبًا للبيانات. تُعرف هذه السلسلة باسم " الاستغلال" .

يُعدّ RAII (استحواذ الموارد أثناء التهيئة ) أسلوبًا شائعًا لحلّ هذه المشكلة في لغات C++ و D و Ada . يتضمن هذا الأسلوب ربط الكائنات ذات النطاق المحدد بالموارد المكتسبة، وتحرير هذه الموارد تلقائيًا بمجرد خروج الكائنات من نطاقها. وعلى عكس جمع البيانات المهملة، يتميز RAII بمعرفة متى تكون الكائنات موجودة ومتى لا تكون. قارن الأمثلة التالية بلغة C وC++:

شركة:

#include <stdlib.h>void someOperation ( int * a ) { // ... }void f ( int n ) { int * a = ( int * ) calloc ( n , sizeof ( int )); someOperation ( a ); free ( a ); }

في لغة C++:

استيراد std ؛باستخدام std :: vector ;void someOperation ( vector < int >&a a ) { // ... }void f ( int n ) { vector < int > a ( n ); someOperation ( a ); }

يتطلب إصدار C، كما هو مُطبق في المثال، تحريرًا صريحًا للذاكرة؛ حيث يتم تخصيص المصفوفة ديناميكيًا (من الذاكرة الديناميكية في معظم تطبيقات C)، وتستمر في الوجود حتى يتم تحريرها صراحةً. (لاحظ أنه على عكس malloc()، calloc()يقوم بتهيئة جميع العناصر إلى 0.)

لا يتطلب إصدار C++ تحريرًا صريحًا للذاكرة؛ إذ يتم ذلك تلقائيًا بمجرد aخروج الكائن من نطاق التعريف، حتى في حالة حدوث استثناء. وهذا يُجنّبنا بعضًا من أعباء آليات جمع البيانات المهملة . ولأن مُدمّرات الكائنات قادرة على تحرير موارد أخرى غير الذاكرة، فإن RAII يُساعد في منع تسريب موارد الإدخال والإخراج التي يتم الوصول إليها عبر مُعرّف ، والتي لا تتعامل معها آلية جمع البيانات المهملة القائمة على التحديد والمسح بكفاءة. وتشمل هذه الموارد الملفات المفتوحة، والنوافذ المفتوحة، وإشعارات المستخدم، والكائنات في مكتبة رسومات، وعناصر مزامنة الخيوط مثل المقاطع الحرجة، واتصالات الشبكة، والاتصالات بسجل ويندوز أو قاعدة بيانات أخرى.

مع ذلك، فإن استخدام RAII بشكل صحيح ليس بالأمر السهل دائمًا، وله عيوبه. على سبيل المثال، إذا لم يتوخَّ المرء الحذر، فمن الممكن إنشاء مؤشرات (أو مراجع) معلقة عن طريق إرجاع البيانات بالمرجع، ليتم حذف تلك البيانات عند خروج الكائن الحاوي لها من نطاق التعريف.

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

تعتمد معظم أنظمة جمع البيانات المهملة الحديثة على مفهوم إمكانية الوصول  ؛ فإذا لم يكن لديك مرجع قابل للاستخدام إلى الذاكرة المعنية، يُمكن جمعها. بينما تعتمد أنظمة أخرى على عدّ المراجع ، حيث يكون الكائن مسؤولاً عن تتبع عدد المراجع التي تشير إليه. إذا انخفض العدد إلى الصفر، يُفترض أن يُحرر الكائن نفسه ويسمح باستعادة ذاكرته. يكمن عيب هذا النموذج في عدم قدرته على التعامل مع المراجع الدورية، ولهذا السبب يُفضل معظم المبرمجين اليوم استخدام أنظمة "التحديد والمسح" الأكثر تكلفة.

يوضح كود Visual Basic التالي تسرب الذاكرة القياسي الناتج عن عد المراجع:

Dim A , B Set A = CreateObject ( "Some.Thing" ) Set B = CreateObject ( "Some.Thing" ) ' عند هذه النقطة، يكون لكل من الكائنين مرجع واحد،Set A . member = B Set B . member = A ' الآن لكل منهما مرجعان.المجموعة أ = لا شيء ' لا يزال بإمكانك الخروج من هذا الوضع...Set B = Nothing ' والآن لديك تسرب للذاكرة!نهاية

عملياً، يمكن رصد هذا المثال البسيط وتصحيحه فوراً. أما في معظم الأمثلة الواقعية، فتمتد سلسلة المراجع لأكثر من عنصرين، ما يجعل اكتشافها أكثر صعوبة.

برز مثال معروف لهذا النوع من التسريب مع ظهور تقنيات برمجة AJAX في متصفحات الويب ، وتحديدًا مشكلة المستمع المنتهي الصلاحية . فقد كان كود جافا سكريبت الذي يربط عنصر DOM بمعالج أحداث، ويفشل في إزالة المرجع قبل الخروج، يتسبب في تسريب الذاكرة (تحتفظ صفحات الويب التي تستخدم AJAX بعنصر DOM معين لفترة أطول بكثير من صفحات الويب التقليدية، لذا كان هذا التسريب أكثر وضوحًا).

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

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

• تجاوز سعة المخزن المؤقت
• إدارة الذاكرة
• مصحح أخطاء الذاكرة
• Plumbr هي أداة شائعة للكشف عن تسرب الذاكرة للتطبيقات التي تعمل على آلة جافا الافتراضية .
• nmon (اختصار لـ Nigel's Monitor) هي أداة مراقبة نظام شائعة لأنظمة التشغيل AIX و Linux.

• برنامج Visual Leak Detector، مؤرشف بتاريخ 15 ديسمبر 2015 على موقع Wayback Machine ، وهو برنامج مفتوح المصدر خاص بـ Visual Studio
• فالغريند ، مفتوح المصدر
• Deleaker for Visual Studio، برنامج احتكاري
• أداة التحقق من الذاكرة لبرامج Visual Studio و Delphi و Fortran و Visual Basic، وهي ملكية خاصة.
• اكتشاف تسرب الذاكرة (باستخدام دعم تصحيح الأخطاء في MFC)
• مقال بعنوان " الكشف عن تسرب الذاكرة في الأنظمة المدمجة " بقلم كال إريكسون
• برنامج WonderLeak ، وهو برنامج تحليل أداء عالي لتخصيص الذاكرة ومعالجتها في نظام ويندوز، وهو برنامج خاص.