Garbage collector in .Net

الجزء الثانى

Finalization process

زى ماعرفنا سابقا أن لوعندى فى البرنامج unmanaged resources يبقى لازم أقول للCLR إزاى يعمل clean لتلك المصادر وذلك أول technique تعريف الfinalize method حيث تلك الدالة موجودة فى الMaster class (object) كما موضح

    public class object
{
    protected virtual void Finalize()
{}
}

حيث تلك الدالة يتم مناداتها أوتوماتيك فى حالة إنتهاء الApplication domain (APPDomain يستخدم لإستضافة الexecutable Assembly or external libraries ) وبالتالى بديهى كدة لو حبيت أنشاء كلاس بة مصادر غير مدارة يبقى أنا لازم أعمل override لتلك الدالة كما موضح فى ذلك الكود

class UnManagedResources
    {
   //Error 
        protected override void Finalize()
        {
            //write unmanaged resurces such using COM interoperability tasks.
        }

}

حيث عند عمل compile للبرنامج ستجد خطأ كما موضح

"Don't override object.Finalize instead provide a destructor"

معنى كدة من الخطأ الموضح أن لو حيبت أعرف الfinalize يبقى أعرفها بس بطريقة غير مباشرة عن طريق أستخدام الdestructor لية؟؟

لان الكود المكتوب داخل الdestructor يتم وضعة داخل الfinalize فى الCIL كما سنرى

وبالتالى سيتم تعديل الكود كما يلى

  class UnManagedResources
    {       
        //write unmanaged resurces such using COM interoperability tasks.
        //.......
        ~UnManagedResources ()
        {
            //Clean up unmanaged resources here.

            //Beep when destroyed(kust for testing)
            Console.Beep();
        }
        //.......
 }

وعند عمل run للبرنامج وفتح الEXE بواسطة الildasm.exe ستجد الdestructor عبارة عن دالة الfinalize والكود اللى مكتوب داخل الdestructor مكتوب بين try-finally كما موضح

Detailing the Finalization process

عند حجز مساحة للobject فى الheap حيث الruntime أوتوماتيك يشوف هثل ذلك الobject يدعم الfinalize() لو كان كذلك يعرف الكائن بfinalizable object وبالتالى يتم حجز مؤشر لذلك الكائن داخل طابور يسمى Finalization queue

حيث الFinalization queue عبارة عن طابور يتم التحكم فية عن طريق الGC حيث كل كائن داخل ذلك الطابور يوجد لة الfinalize method الخاصة بة التى سيتم مناداتها قبل عمل تصليح للذاكرة من ذلك الكائن

حيث كما موضح فى تلك الصورة عندنا مجموعة من الكائنات الموجودة داخل الheap بعضها متصل بالroot الخاص بة والبعض الاخر unreachable عند إنشاء مجموعة من الكائنات مثلC,E,F,I,J حيث كل كائن من تلك الكائنات معرف لة الfinalize method وبالتالى هيجيى الruntime ويعرف أن كل كائن من الكائنات معرف لة الfinalize method وبالتالى سيتم إضافة مؤشر لكل كائن داخل الfinalization queue كما موضح فى تلك الصورة

على إفتراض ان تلك الكائنات لم يعد لها أى إستخدام وهم B,E,G,H,I,J وبالتالى سيبدأ الGC فى عملة المعتاد

أول حاجة هيعملها أنة هيعمل scan على الfinalization queue هل فى مؤشر لأى كائن من الunreachable objects ولالأ لو فية زى فى حالتنا زى الobject E,J,I وبالتالى سيتم حذف ذلك المؤشر من الfinalization queue ووضعة فى freachable queue (حيث عبارة عن طابور يتم التحكم فية عن طريق الGC ويحتوى على مؤشر للكائنات التى على أستعداد ليتم مناداة الfinalize method

حيث فى تلك الصورة ستجد أن الكائنات التالية B,G,H تم عمل reclaimed لهم وذلك لان تلك الكائنات لا تملك الfinalize method أما الكائنات E,I,J لم يتم عمل reclaim لهم لانهم منتظرين مناداة الfinalize الخاصة بكل كائن منهم

كما موضح فى تلك الصورة

حيث توجد thread خاصة بالقيام بعملية الreclaim للكائنات الموجودة داخل الfreachable queue حيث تلك الthread تنشط عندما يتم وضع أى كائن داخل ذلك الqueue وبالتالى يتم حذف مؤشر كل كائن من ذلك الطابور ومناداة الدالة الخاصة بة ليتم عمل reclaim للذاكرة.

Freachable queue حيث الf تدل على ان ذلك الكائن منتظر لfinalization operation وأن كل كائن لة finalize method أما الreachable تدل على أن ذلك الكائن مازال reachable حيث يتم إعتبار المؤشر الموجود داخل الfreachable queue بالroot .بعد عمل reclaim للكائنات الاخرى سيتم عمل reclaim للكائنات الموجودة داخل الfreachable queue

كما موضح فى تلك الصورة

IDisposable interface

يوجد البديل لإستخدام الfinalize method وهو تعريف الDispose method الموجودة داخل الIDisposable interface

public interface IDisposable
    {
        public void Dispose();
    }

وبالتالى عند عمل Implements لذلك الinterface يبقى أقدر أستخدم تلك الدالة حيث يتم إستدعائها Manually كما فى ذلك الكود

class UnManagedResources:IDisposable
    {       
        //write unmanaged resurces such using COM interoperability tasks.
        //.......
       public void Dispose()
        {
            //Clean up unmanaged resources here.

           
        }
        //.......
        
    }

    
    class Program
    {
        static void Main(string[] args)
        {
            UnManagedResources obj = new UnManagedResources();
            if (obj is IDisposable) //Check if obj support Dispose method
            {
                obj.Dispose();
            }
        }

حيث الفرق بينهما أن الfinalize مقتصرة فقط على الclasses أما الDispose ممكن يتم عمل implement لها عن طريق class or struct

حيث فى أغلب أستخدام الdispose يتم أستدعائها داخل الfinally block كما موضح

UnManagedResources obj = new UnManagedResources();
            try
            {
                //use obje members here
            }

            finally
            {
                //Always call dispose 
                obj.Dispose();
            }

حيث ممكن الاستغناء عن ذلك عن طريق أستخدام الusing keyword كما يلى

//Dispose method called automatic when exit from using scope.
            using (UnManagedResources obj = new UnManagedResources())
            {
                //use obj members here     
            }

حيث عند إستخدام الusing keyword وفتح الEXE عن طريق ildasm.exe سنجد الusing عبارة عن try-finally وإستدعاء الdispose داخل الfinally block

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
// Code size       29 (0x1d)
  .maxstack  2
  .locals init ([0] class ConsoleApplication5.UnManagedResources obj,
           [1] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  newobj     instance void ConsoleApplication5.UnManagedResources::.ctor()
  IL_0006:  stloc.0
  .try
  {
    IL_0007:  nop
    IL_0008:  nop
    IL_0009:  leave.s    IL_001b
  }  // end .try
  finally
  {
    IL_000b:  ldloc.0
    IL_000c:  ldnull
    IL_000d:  ceq
    IL_000f:  stloc.1
    IL_0010:  ldloc.1
    IL_0011:  brtrue.s   IL_001a
    IL_0013:  ldloc.0
    IL_0014:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
    IL_0019:  nop
    IL_001a:  endfinally
  }  // end handler
  IL_001b:  nop
  IL_001c:  ret
} // end of method Program::Main

Use Finalize and Dispose methods

إحنا عرفنا أن الFinalize يتم إستدعائها أوتوماتيك قبل حذف الكائن أما الDispose يتم إستدعائها يدويا او أوتوماتيك عن طريق أستخدام using keyword للتأكد من أن الdispose تم مناداتها كما عرفنا

حيث فى بعض البرامج يتم تعريف الدالتين علشان لو نسيت ولم أستخدم الdispose أو الusing keyword يبقى الfinalize هيتم إستدعائها أوتوماتيك أما لو أستخدمت الdispose يبقى فى تلك الحالة لازم أعرف الGC أن مايستدعيش الfinalize مرة أخرى وذلك عن طريق GC.SuppressFinalize() وبالتالى كدة هبقى متأكد أن الunmanged resources كدة كدة هيتم عمل clean لها

class UnManagedResources:IDisposable
    {
        //The garbage collector will call this destructor if the
        // object user forgets to call Dispose().
        ~UnManagedResources()
        {
            //Clean up unmanaged resources here.
        }

       public void Dispose()
        {
            //Clean up unmanaged resources here.
            
           //NO need to use finalize now 
            GC.SuppressFinalize();
           
        }
        //.......

}

وطبعا زى ما إحنا شايفين فى تكرار فى الكود حيث الfinalize تستخدم فقط للunmanaged resources أما الdispose ممكن تستخدم فى حالة الmanaged resources وبالتالى فى تلك الحالة هستخدم الFormalized Disposal pattern أو(Prim and proper disposal pattern ) حيث أنة قابل للتعديل وللصيانة

أنظر الى ذلك الكود

class UnManagedResources:IDisposable
    {
        //Used to determine if Dispose() has been already called
        private bool disposed = false;

        //The garbage collector will call this destructor if the
        // object user forgets to call Dispose().
        ~UnManagedResources()
        {
            //Call our helper method
            //Specifying 'false' signifies that GC triggered the clean up.
            CleanUp(false);
        }

       public void Dispose()
        {
            //Call our helper methods

            // Specifying "true" signifies that
            // the object user triggered the clean up.
            CleanUp(true);
            

           //NO need to use finalize now 
            GC.SuppressFinalize(this);
           
        }

        private void CleanUp(bool disposing)
        {
            //Be sure that we haven't already been dispoesed
            if (!this.disposed)
            {
                //if disposing  == true then dispose  all managed resources.
                if (disposing)
                {
                    //Dispose managed resources.
                }
                //clean up unmanaged resources.
            }

            disposed = true;
        }
        //.......
        }

Resurrection (الإحياء)

طبعا عرفنا سابقا أن الكائن الذى لم يعد لة أى إستخدام بيكون unreachable object يعنى كائن ميت على الرغم من أنة لو كان منتظر الfinalize method سيظل الكائن reachable يعنى حى حتى يتم مناداة الfinalize() وبالتالى يعتبر الكائن المنتظر الى الfinalize() عبارة عن

1-unreachable 2-reachable 3-unreachabel حيث كل خطوة من دول ناتجة من

1 من البرنامج يعنى من الApp root

2-من الfinalization queue حيث يعتبر المؤشر الموجود داخل الطابور وكأنة الroot لذلك الكائن

3-وجود الكائن داخل الfreachable queue ومنتظر مناداة الfinalize وتم عمل clean لة

حيث فائدة الResurrection رجوع الكائن من الunreachable الى reachable

عند وجود الكائن داخل الfreachabel queue ومنتظر مناداة الfinalize() ليتم تدميرة نهائيا فما بالك لو عند مناداة الfinalize يتم عمل مؤشر لذلك الكائن المراد تدميرة داخل static object كما موضح فى ذلك الكود

class BaseObj
    {
        ~BaseObj()
        {
            Application. ObjHolder = this;
            GC.ReRegisterForFinalize(this);
        }
    }
    class Application
    {
        public static object ObjHolder; //Default null.
    }

حيث عند تنفيذ الfinalize سيتم إنشاء root لذلك الكائن (this المراد إحيائة) عن طريق الObjHolder وبعد ذلك يتم مناداة الGC.ReRegisterForFinalize(object obj) حيث تعمل على وضع مؤشر لذلك الكائن (this ) داخل الfinalization queue وفى تلك الحالة تم تحويلة من unreachable الى reachable object أما فى حالة إكتشاف أن ذلك الكائن(this ) ليس لة أى إستخدام إذن يتم وضع لة مؤشر داخل الfreachable queue وبعد ذلك مناداة الfinalize() التىتعمل على إحياء ذلك الobject (this ) مرة أخرى.

حيث يفضل عدم إستخدام ال Resurrection بسبب تؤدى الى نتائج غير متوقعة (وصراحة أنا مش عارف عملية الاحياء دى تستخدم فى أية؟؟؟ )

Weak Reference

عندما الroot يشير الى الكائن وبالتالى الGC ميقدرش يعمل clean لذلك الكائن بسبب وجود root لة فى تلك الحالة يسمى بالStrong Reference to object وأيضا بما أن يوجد strong reference يوجد أيضا Weak Reference فى تلك الحالة ممكن الGC يعمل collect للكائن وبعد ذلك يتم إستخدامة مرة أخرى .

فى حالة أن الGC نيشط ووجد weak reference لكائن سيتم عمل collect لة عن طريق الGC

وبالتالى ليس متاح لنا إستخدام ذلك الكائن مرة أخرى إلا فى حالة تحويلة الى Strong reference كما سنرى

فائدة الWeak reference تستخدم للتقليل من الظغط الناتج من الكائنات الضخمة الموجودة داخل الManaged heap

مثال واقعى

على إفتراض عمل برنامج يستخدم لعرض جميع الdirectories and files on user's hard desk in simple tree

والمشكلة هنا أن الtree ممكن تكون كبيرة جدا وحاجزة مساحة كبيرة جدا من الذاكرة وعلى إفتراض أن المستخدم فى فترة إستخدامة للtree تركها وإستخدم جزء أخر من البرنامج وبالتالى لإحنا كدة عندنا waste space طب والحل أن إحنا نعمل delete للtree طب على أفتراض أن المستخدم حب يرجع مرة أخرى الى الtree هل هعيد نباء الtree مرة أخرى

الحل أن نستخدم الWeak Reference

فى حالة ان المستخدم ترك الtree وأشتغل بحاجة تانية فى البرنامج يتم عمل weak reference للtree وحذف جميع الstrong reference الخاصة بالtree . وفى حالة رجوع المستخدم مرة أخرى الى الtree يتم تحويل من weak reference الى strong reference ويتم إستخدامها مرة أخرى .

يحتوى الWeak reference class على two constructors كما موضح

WeakReference(object target)
WeakReference(object target,bool trackResurrectio)

حيث الtarget parameter يدل على الكائن المراد عمل weak reference لة أما الparameter الثانى وهو هل ذلك الكائن سيتم عمل لة weak reference بعد أم قبل إحياءة (رجوعة من الunreachable الى reachable ) حيث كما عنرفنا سابقا لا يفضل إستخدام ال Resurrection وبالتالى ذلك المتغير دائما بيكون بfalse وبالتالى دائما يتم إستخدام الfirst constructor

عند لإستخدام الconstructor التانى فى حالة إستخدامنا الResurrection operation يسمى بالlong weak reference أما فى الحالات الاخرى يسمى بshort weak reference

تعالى نشوف مثال بسيط

Void Method() {
   Object o = new Object();    // Creates a strong reference to the
                               // object.

   // Create a strong reference to a short WeakReference object.
   // The WeakReference object tracks the Object.
   WeakReference wr = new WeakReference(o);

   o = null;    // Remove the strong reference to the object

   o = wr.Target;
   if (o == null) {
      // A GC occurred and Object was reclaimed.
   } else {
      // a GC did not occur and we can successfully access the Object 
      // using o
   }
}

حيث عند إستخدام الكئن o مرة أخرى يتم التحويل من short weak reference الى strong reference عن طريق Target property وإرجاعها لroot بتاع ذلك الكائن

فى حالة رجوع null يبقى تم عمل reclaim لذلك الكائن أما فى حالة عدم إرجاع null وبالتالى الكائن متاح إستخدامة مرة أخرى.

وبكدة يكون الدرس إنتهى ويارب تكونوا إستفدتوا وياريت لو فى أى أخطاء فى الشرح تفيدونا وأعتذر عن التطويل :)

بسم الله الرحمن الرحيم

جزاك الله عنا خيرا شرح اكثر من ممتاز ولكن انا مبتدىء ولا اعرف

عن ماذا تتكلم فلو تكرمت ممكن تقربلى المعنى شوية وخاصتة المعانى امثال

الGarbage collection الManaged heap الApplication root

ومن هذه المعانى

وللك جزيل الشكر اخى علام

وشكرا لقراءة رسالتى

والسلام عليكم ورحمة الله وبركاتة

اقتباس

garbage collection

بالنسبة لعملية الMemory management(إدارة الذاكرة ) بتكون من مسئولية الcommon language runtime عن طريق ال

garbage collector

فى حالة أن أنا ممكن أتحكم فى تلك العملية عن طريق أستخدام class إسمة الGC (garbage collector الموجود داخل الSystem namespace حيث الGC يسهل حاجات كتير كانت مشاكل كبيرة مثلا

ممكن أنسى أعمل تدمير للكائن-أحاول أدمر acive object -أحاول أدمر الكائن أكثر من مرة حيث أغلب تلك المشاكل تقابل مبرمجى السى والسى بلس بلس -_-

اقتباس

Managed heap

بص علشان اوضحلك الفرق ألاول ما هو الstack

stack عبارة عن مجموعة من الصناديق الموضوعة فوق بعض لو حبيت أشيل إحدى الصناديق لازم أشيل اللى فوق ذلك الصندوق

أما الheap عبارة عن مجموعة من الصناديق الغير مرتبة كل صندوق موضوع فى مكان وهكذا

وبالتالى الmanaged heap عبارة عن مجموعة من المساحات العشوائية الموجودة داخل الذاكرة التى يتم التحكم بها عن طريق الCLR

حيث الGC يعتبر الHouse keeper للManaged heap :)

طب لية كلمة managed للدقة لا أكثر

كنا فى السى بلس بلس أو السى ممكن تتحكم فى الheap وتضع فية أى حجم من البيانات وبعد ذلك لتحرير تلك الذاكرة من البرنامج المستخدم لكى تعود الى الOS كنت أستخدم الkeyword====>delete ولكن كان يقابل المبمرج المشاكل السابقة وبالتالى سهلت علينا الدوت نت وخلت تلك العملية(عملية الreclaim للذاكرة) من نصيب ال.Net وليس المبرمج كل دة بيحصل عند إستخدام الManaged resources اللى يقدر الCLR ينظف الذاكرة منها أما فى حالة إستخدام الunmanaged resources كدوال الAPI

أو بعض الدوال المهام عن طريق الCOM

اقتباس

Application root

بص ياسيدى لو أنشاءت كائن ذلك الكائن يتم إرجاع عنوانة عن طريق الnew حيث الكائن وبياناتة موجودة داخل الmanaged heap

وعنوان لذلك الكائن موجود داخل الstack حيث المتغير الموجود داخل الstack يعتبر الroot لذلك الكائن الموجود بياناتة داخل الheap فى حالة عدم وجود ذلك المتغير يعتبر الكائن unreachable object .

وياريت لو تدخل على اللينكتين دول علشان تعرف ماهو الvalue type and reference type وما هو الheap

Reference types VS Value types Part I

Reference types VS value types Part II

أتمنى أن المفاهيم تكون وضحت وأكون أفدتك :)

من المواضيع الهامة التى أختفت بمرور الزمن !

الله ينور يا باشمهندس ،، تسلم ايدك