مقال تقني: Memory Leaks In .NET
بيئة التطوير : جميع إصدارات الفيجوال ستوديو بدءًا من 2003
اللغة #C نفس ما سيرد في هذا الموضوع ينطبق على VB .
المستوى: متقدم (يفترض بقارء الموضوع أن يكون ملماً باساسيات الدوت نت ).
في اللغات الغير مدارة مثل C++ عليك أن تتذكر دائماً بأنه يجب عليك أن تتخلص من الذاكرة التي قمت بتخصيصها من أجل كائن معين عندما تصبح بدون حاجة إليه, وإلا فسيحدث ما يسمى بال Memory Leak أو تسرب الذاكرة , في عالم الدوت نت والمصادر المدارة, إمكانية حدوث ال Memory Leak شبه منعدمة في أغلب الأحيان , والفضل يعود إلى ال CLR وآلية إدارة الذاكرة التي يعتمدها من خلال ال Garbage Collection , ما يعني أن اي كائن يتم تخصيص مساحة من الذاكرة له يتم نحريرها فور انتهاء مدة حياة ذلك الكائن وحالما يصبح بدون أي References .لكن ما يحدث في التطبيقات التي تعمل باستمرار وحيث أن حجم الذاكرة المستهلكة يزداد كلما زادت فترة حياة ذلك التطبيق , فإنه من الممكن حدوث ال Memory Leaks . تحدث مشاكل الذاكرة هذه عادة بسبب الكائنات التي تبقى عالقة في الذاكرة من دون استخدامها داخل تطبيقك , مثال شائع عن مسببات ال Memory Leaks وهي ال MulticastDelegates وبالضبط ال EventHandlers فمثلا عندما تقوم بربط EventHndler من كائن A إلى EventHandler لكائن B ولم تقم بفصل هذا الارتباط فسيبقى الكائن B عالقاً في الذاكرة ولن تقوم GC بجمعه حتى عندما تسند القيمة null أو Nothing له لأنه لازال هناك مرجع من الكائن A يشير إلى الكائن B , والمثال التالي يوضح ذلك:
رمز:
public class Server
{
public EventHandler handler;
}
public class Client
{
Server _server = null;
public Client(Server server)
{
this._server = server;
this._server.handler += new EventHandler(Handle);
}
private void Handle(object sender, EventArgs e)
{
// Do something
}
}
لنفترض بعد ذلك أنك قمت بإنشاء 2000 نسخة Instance من الفئة Client :
رمز:
class Test
{
Server server = new Server();
public Test()
{
for (int i = 0; i < 2000; i++)
{
var client = new Client(this.server);
}
}
}
}
قد يخطر في بالك أنه بعد الانتهاء من استخدام ال 2000 كائن سيتم تدميرهم وتحرير الذاكرة التي كانو يشغلونها وهذا خاطئ , سيبقى الألفين كائن معلقين في الذاكرة والسبب ان كل منهم لا يزال يرتبط بالكائن server الخاص بالفئة Test عن طريق ال EventHandler حيث قمنا بإنشاء هذا الارتباط داخل الConstructor الخاص بالفئة Client ولكنا لم نقم بالتخلص من هذا الارتباط وذلك بعمل Unsubscribing لل Eventhandlers, وفي العادة يتم فصل هذا الارتباط عن طريق تحقيق الواجهة IDisposable للفئة Client ويكون ذلك داخل الإجراء Dispose كما هو موضح في الكود التالي:
رمز:
public class Client : IDisposable
{
Server _server = null;
bool disposed = false;
public Client(Server server)
{
this._server = server;
this._server.handler += new EventHandler(Handle);
}
private void Handle(object sender, EventArgs e)
{
if (disposed) throw new ObjectDisposedException("client");
// Do something
}
public void Dispose()
{
this._server.handler -= new EventHandler(Handle);
this.disposed = true;
}
}
الآن وباستخدام using Statement أو استدعاء الإجراء Dispose يمكنك التأكد من أنه سيتم فصل الارتباط وتحرير ال 2000 كائن في المرة التالية التي يتم فيها عمل Garbage Collecting للذاكرة بعد الانتهاء من ال using Block كما يوضح المثال التالي:
رمز:
class Test
{
Server server = new Server();
public Test()
{
for (int i = 0; i < 2000; i++)
{
using (var client = new Client(this.server))
{
// Do something...
}
}
}
}
وبالرغم من ذلك فإن هذا الحل لن يكون الأفضل فقد تضطر لعدم استخدام الواجهة Idisposable عندها لابد من استخدام الفئة
[size=12]المؤقتات Timers
يمكن أيضًا للمؤقتات المتوفرة قي الدوت نت أن تتسبب في تسرب الذاكرة , وهناك حالتان مختلفتان حسب نوع المؤقت الذي نتعامل معه , لنلق نظرة على الفئة Timer الموجودة ضمن مجال الأسماء System.Timers , بالنظر إلى المثال التالي فإنه عند إنشاء نسخة منها سيتم استدعاء الإجراء Timer_Tick كل ثانية:
رمز:
class TimerTest
{
Timer timer = new Timer { Interval = 1000};
private TimerTest()
{
this.timer.Elapsed += Timer_Tick;
this.timer.Start();
}
private void Timer_Tick(object sender, ElapsedEventArgs e)
{
Console.WriteLine("Tick!");
}
}
ولسوء الحظ , فإن هذا الكائن سيبقى عالق إلى حتى ينتهي التطبيق ولن تتمكن GC من التقاطه والسبب أن الدوت نت نفسه يحتفظ بمرجع إلى جميع المؤقتات النشطة من النوع System.Timers.Timer من جهة , ومن جهة أخرى فإن كائن Timer نفسه مرتبط مع EventHandler الخاص بفئتك , وفي هذه الحالة لن يفيدك القيام ب Unsubscribing لل EventHandler وحده, بل عليك أيضًا استخدام الواجهة IDisposable واستدعاء الإجراء Dispose الخاص بالفئة Timer داخل الإجراء Dispose الخاص بفئتك. كما هو موضح في الكود التالي:
رمز:
class TimerTest : IDisposable
{
Timer timer = new Timer { Interval = 1000};
bool disposed = false;
private TimerTest()
{
this.timer.Elapsed += Timer_Tick;
this.timer.Start();
}
private void Timer_Tick(object sender, ElapsedEventArgs e)
{
if (disposed) throw new ObjectDisposedException(GetType().FullName);
Console.WriteLine("Tick!");
}
public void Dispose()
{
timer.Dispose();
timer.Elapsed -= Timer_Tick;
this.disposed = true;
}
}
نفس الكلام السابق ينطبق على الفئة System.Windows.Forms.Timer .
الأمر مختلف بالنسبة للفئة System.Threading.Timer , فهو من نوع خاص, فالدوت نت لا تحتفظ بأي مراجع نحو المؤقتات النشطة من هذا النوع , ولكنها تحتفظ بال Callback Delegate الذي يتم تمريره لل Constructor وهذا يعني أنك إذا نسيت استدعاء الإجراء Dispose الخاص بالفئة Timer فسيتم ستدعاء ال Fimalizer الخاص بها في أي لحظة ما يعني احتمال حدوث خطأ غير متوقع في سير عمل برنامجك بعد تدمير ال Timer , جرب المثال التالي في الوضع Release بدل الوضع Debug.
رمز:
Timer t = new Timer(delegate { Console.WriteLine("Tick"); }, null, 1000, 1000);
GC.Collect();
Thread.Sleep(10000);
لاحظ أنه إذا قمت بتجربة الكود السابق فإن المؤقت لن يعمل ولو لمرة واحدة وسيتم عمل Finalizing له وجمعه عند استدعاء GC.Collect بشكل صريح. وحتى تتمكن من حل المشكلة لا بد من استخدام ال using Statement حتى تضمن أن GC لن يستطيع الوصول إلى المؤقت وجمعه. والاستدعاء الضمني للإجراء Dispose في نهاية ال using Block يضمن ذلك, ولكن استدعاء Dispose في هذه الحالة قد يطيل عمر المؤقت في الذاكرة!
معالجة مشاكل ال Memory Leaks:
أسهل طريقة يمكن من خلالها تجنب مشاكل تسرب الذاكرة من خلال قياس كمية الذاكرة المستهلكة طوال فترة كتابة البرنامج, يمكنك الحصول على قدر الذاكرة التي تستهلكها كائنات برنامجك باستخدام الإجراء GC.GetTotalMemory , حيث يمكن تمرير قيمة منطقية , فإن قمت بتمرير True فذلك سيجعل الGC تقوم بعمل Garbage Collecting أولاً:
رمز:
Console.WriteLine(GC.GetTotalMemory(true));
إذا كنت تعمل على تطبيق تستخدم فيه Unit Tests يمكنك القيام بعمليات التحقق من أن الذاكرة يتم تحريرها كما هو متوقع وإذا فشل أي تحقق Assertion فعليك التحقق عندها فقط من التغييرات الأخيرة التي قمت بها في تطبيقك.
إذا كنت تعمل على تطبيق ضخم وتعاني من مشكلة بسبب حدوث تسرب في الذاكرة , فقد تساعد الأداة windbg.exe على اكتشافها , هناك أيضأ بعض الأدوات التي تعتمد على واجهة رسومية تساعد على فهم مايحدث بالضبط مثل Microsoft CLR Profiler , و SciTech Memory Profiler , و RedGate ANTS Memory Profiler , وال CLR نفسه يحتوي على مجموعة من الأداوت المساعدة مثل WMI Counters التي تساعد على مراقبة الموارد Resources التي يستهلكها البرنامج.
[/size]
الأحد مايو 03, 2015 11:15 pm من طرف 
