مديريت حافظه

درباره مديريت حافظه CLR بيشتر در زمينه VB بحث مي کنيم.

مديريت بهتر بر Garbage Collection:

Runtime در ويژوال بيسيک داراي سيستم خود کار براي Garbage Collection ها است. در ويژوال بيسيک 6، runtime به شکل خودکار منابع را از شئ هايي که ديگر توسط برنامه استفاده نمي شوند مي گيرد. براي مثال فرض کنيد مي خواهيم يک فايل LOG ايجاد کنيم، براي اين کار مي توان از دو شئ Scripting.Stream و Scripting.FileSystemObject استفاده کرد. اگر اين دو شئ را در تابعي به کار ببريم، بعد از اتمام عمليات، runtime منابع اختصاص داده شده به اين دو شئ را مي گيرد. اما مواردي وجود دارد که runtime به آساني امکان تشخيص شئ و زمان بلااستفاده بودن آن را ندارد.

Cyclical References:

يکي از مهمترين زمانهايي که runtime مربوط به VB نمي تواند تشخيص بدهد که آيا يک شئ به منابعي احتياج دارد يا اينکه کارش به پايان رسيده زماني است که در متن برنامه حالتي به نام Cyclical Reference بوجود بيايد. به عنوان مثال اگر شئ A به صورت reference از شئ B استفاده کند و همچنين شئ B از A.
هر شئ COM مسئول نگهداري تعداد دفعاتي است که فعال شده است. بدين صورت که هر بار از روي آن ساخته شود با AddRef و هربار که يک برنامه آن را رها کند با Release از IUnKnown interface شمارنده اي را يکي افزايش يا کاهش مي دهد. اگر آن شمارنده به صفر برسد شئ تمامي منابع خود را آزاد مي کند، اما اگر هنگامي که يک شئ COM غير فعال شود ولي از Release استفاده نشود يک شئ بلا استفاده در حافظه مي ماند.
runtime مربوط به VB 6 اين کار را به صورت خودکار انجام مي دهد، اما هنگامي که دو شئ به هم اشاره مي کنند بحث فرق مي کند و runtime به شکل حالت ساده نمي تواند يک شئ را از حافظه بردارد. براي مثال به قطعه برنامه زير توجه کنيد.

'Class : CCyclicalRef Dim m_objRef as Object    Public Sub Initialize(objRef as Object)       Set m_objRef = objRef EndSub    Private Sub Class_Terminate()       Call Msgbox("Terminating.")       Setm_objRef = Nothing End Sub

در کلاس CCyclicalRef متدي با نام Initialize تعريف شده است که در پارامتر هاي خود يک شئ را مي پذيرد و از روي آن يک شئ ديگر مي سازد. حال از کلاس تعريف شده در کد زير استفاده مي کنيم.

Dim objA as New CCyclicalRef Dim objB as NewCCyclicalRef    Call objA.Initialize(objB) Call objB.Initialize(objA)    Set objA = Nothing Set objB = Nothing

ابتدا دو نمونه از روي کلاس CCyclicalRef با نامهاي objA و objB ساختيم، حال هر دوي اين شئ ها يک بار ساخته شده اند و شمارنده آنها يک است. با استفاده از متد Initialize هر دوي شئ ها، آدرس حافظه يکديگر را مبادله مي کنند و به اين شکل از روي هر دوي آنها يک بار ديگر ساخته مي شود و شمارنده هر دو، 2 مي شود. شماره يک مربوط به خود برنامه است و شماره دوم مربوط به شئ هايي که به هم اشاره مي کنند. سپس هر دوي آنها را برابر nothing قرار مي دهيم تا آنها را از حافظه حذف کنيم. در اينجا شمارنده هر دو يکي کم و برابر يک مي شود. بنابراين برنامه terminate شده است ولي هنوز شئ در حافظه وجود دارد.

Garbage Collector در CLR:

روش Garbage Collector در CLR با VB 6 Runtime تفاوت دارد. در روش جديد که خود ِ CLR و GC مسئول اجراي آن هستند، آخرين باري که از nothing استفاده مي شود ولي هنوز شئ در حافظه مانده باشد، GC اين وضعيت را درک مي کند و آن شئ را بعد از مدتي از حافظه خارج مي کند. شئ هايي هستند که مانند COM مسئول غير فعال کردن خود نيستند، GC آنها را نيز تشخيص داده و اگر برنامه اي ديگر از آنها استفاده نکند، از حافظه حذف مي شوند.

Finalize:

GC متد Object.Finilize را قبل از اينکه هر شئ را از حافظه حذف کند صدا مي زند. اين متد مي تواند در هر زماني بعد از اينکه برنامه ديگر از شئ استفاده نکرد صدا زده شود، لذا در هنگام استفاده از اين متد بايد نکته را در نظر گرفت. درNET. بهتر است قبل از اينکه يک شئ بوسيله nothing از بين برود از متد Dispose يا Close استفاده شود تا سريعا ً از حافظه حذف شود.

روش سريعتر تخصيص حافظه به شئ ها

هر زمان که يک برنامه يک شئ بسازد حافظه اي به آن اختصاص مي يابد، آن حافظه در virtual memory است که براي هر برنامه اختصاص مي يابد و به آن heap گفته مي شود. CLR مفهومي به نام Managed Heap دارد بدين معني که شئ ها را مديريت مي کند و آنها را در يک Heap ِ مديريت شده قرار مي دهد و CLR مسئول حفاظت آنهاست.
از مزاياي اين روش اين است که راندمان سرعت اختصاص دادن حافظه بالا مي باشد. به طور کلي وقتي کُد هاي مديريت نشده در Heap هاي مديريت نشده قرار مي گيرند، به دنبال جايي در حافظه مي گردند که بتوانند خود را در آن قرار دهند. در CLR شئ‎اي که ساخته مي شود هميشه در بالاي آخرين شئ‎اي که ساخته شده در heap قرار مي گيرد. تصوير مربوطه را در اين آدرس مشاهده کنيد.
ابتدا CLR حافظه اي براي شئ هاي A، B و C بر روي Heap در نظر مي گيرد. سپس شئ B از حافظه حذف مي شود، در ادامه نيز برنامه يک شئ ديگري به نام D مي سازد و آن را بر روي آخرين شئ‎اي که ساخته شده بود يعني C قرار مي دهد. اين روش براي اختصاص حافظه سريع است. اما اگر CLR به انتهاي heap برسد چه عملي بايد انجام دهد؟ همان طور که مشاهده کرديد اين روش به شکل افزايشي شئ ها را در حافظه قرار مي دهد. وقتي CLR ديگر نتواند از حافظه استفاده کند GC را فرا مي خواند. GC هم فضاهايي مانند B را کاملا ً آزاد مي کند و هم شئ ها را فشرده مي کند و در پايين heap قرار مي دهد تا بالاي heap آزاد باشد.

پردازش هاي مبتني بر Client Server

در اواسط دهه 80 ميلادي و زمانيكه اولين بار توليدكنندگان تجهيزات شبكه، محصولات خود را به بازار عرضه كردند، واژه Client/Server وارد عرصه كامپيوتر گرديد. در آن زمان واژه فوق صرفا در رابطه با تجهيزات سخت افزاري ( كامپيوتر ) استفاده مي شد و كامپيوتري كه از آن بعنوان مركز ثقل ارائه خدمات در يك شبكه ياد مي شد، را با نام Server و كامپيوتري كه از اين امكانات استفاده مي كرد را بعنوان Client مي شناختند ( سايه نرم افزار بر اين واژه حضور سنگيني نداشت ).
امروزه واژه فوق داراي يك معني خاص است كه چندان مرتبط با سخت افرار نمي گردد. اغلب مردم هنوز واژه Client را به يك كامپيوتر فيزيكي نسبت داده و واژه Server را به كامپيوتر فيزيكي ديگري كه به آن متصل و سرويس هائي را ارائه مي نمايد، اطلاق مي نمايند. مطلب فوق با اينكه درست است ولي صرفا يك بخش اندك از تمامي واقعيت هاي موجود در اين زمينه است. واژه فوق امروزه در مقياس وسيعتري به خدمت گرفته مي شود. بمنظور آشنائي بيشتر با اين واژه لازم است در ابتدا با ساختار و يا معماري عمومي يك نرم افزار آشنا شويم.
اغلب برنامه هاي كاربردي داراي سه لايه اصلي مي باشند :
لايه Presentation: ( بالاترين لايه ) اين لايه مسئول ايجاد ارتباط متقابل بين انسان و كامپيوتر است ( رابط كاربر). لايه فوق مسئوليت گرفتن اطلاعات ورودي از صفحه كليد، ماوس و ساير دستگاههاي ورودي و نمايش اطلاعات ذيربط بر روي دستگاههاي خروجي نظير صفحه نمايشگر است.
لايه Application يا Business Logic: لايه فوق مسئول اعمال و پياده سازي سياست هاي مورد نظر در يك نرم افزار است، در حقيقت با عملكرد لايه فوق است كه مي توان تفاوت بين يك نرم افزار از نرم افزار ديگر را مشاهده و بعنوان مثال تفاوت بين يك نرم افزار ثبت سفارش و يا انبارداري را حس كرد.
لايه Service: اين لايه مسئول ارائه سرويس هاي خاص و مورد نياز براي ساير لايه ها نظير سرويس هاي مربوط به فايل، چاپ، ارتباطي و از همه مهمتر دسترسي به بانك هاي اطلا عاتي است. در ادامه بحث خود را بر روي مجموعه اي از نرم افزارها ئي متمركز خواهيم كرد كه نيازمند سرويس هاي بانك اطلاعاتي باشند.
تعداد طبقات ( Tires )، در يك نرم افزار Client Server به نحوه ارتباط ( متراكم، معمولي ) هر يك از سه لايه گفته شده بستگي خواهد داشت. در ادامه به بررسي مدل هاي رايج در اين زمينه خواهيم پرداخت.

مدل One-Tire

در اين نوع نرم افزارها سه لايه گفته شده بصورت متراكم و فشرده در كنار يكديگر قرار مي گيرند. در مدل فوق لايه Presentation داراي آگاهي خاص و جزئي از ساختار بانك اطلاعاتي است. لايه Application اغلب بصورت موجي با لايه هاي Presentation و Service مرتبط خواهد بود. تمام سه لايه گفته شده بهمراه بانك اطلاعاتي، اغلب بر روي يكدستگاه كامپيوتر قرار گرفته و اجرا خواهند شد. نرم افزارهائي با اين خصوصيت بسادگي طراحي شده و بكمك ابزارهاي برنامه نويسي امروزي بسرعت نوشته خواهند شد.
در صورتيكه بخواهيم يك نرم افزار One-tire با چندين كاربر را طراحي نمائيم، مي توان نرم افزار را بر روي چندين كامپيوتر اجرا و با به اشتراك گذاشتن بانك اطلاعاتي زمينه استفاده از داده هاي موجود در بانك را براي ساير كاربران نيز فراهم نمود. بانك اطلاعاتي را مي توان بر روي يكدستگاه كامپيوتر معمولي در يك شبكه نظير به نظير ( Peer to Peer ) و يا بر روي يك سرويس دهنده فايل ( File Server ) نصب نمود. در اين حالت هر يك از كامپيوترهائي كه برنامه بر روي آنها اجرا مي گردد مي بايست داراي يك نسخه از Database Engine بوده تا قادر به استفاده از داده هاي موجود در بانك اطلاعاتي باشند. در اين مدل صرفا داده ها به اشتراك گذاشته شده و منطق بانك اطلاعاتي به اشتراك گذاشته نشده است. اين نوع از نرم افزارها ( چند كاربره One Tire ) تا زمانيكه تعداد كاربران كم باشد موفق عمل مي نمايند ولي با افزايش تعداد كاربران، با مشكل مواجه مي شوند.
علت عمده بروز مشكل پايبند بودن اين نوع از نرم افزارها به انجام عمليات مربوط به بانك هاي اطلاعاتي بر روي هر يك از سرويس گيرندگان است. مثلا اگر برنامه اي از اين نوع نياز داشته باشد كه ليست تمامي كاربراني را كه نام آنها Reza است، را نمايش دهد، مي بايست تمامي اطلاعات ( ركوردهاي داده و ايندكس هاي مربوطه ) بمنظور پاسخگوئي به درخواست واصل شده، بر روي شبكه فرستاده شود. در برخي حالا ت خاص و با توجه به پيچيدگي درخواست هاي صادر شده براي اطلاعاتي خاص، ممكن است تمامي بانك اطلاعاتي براي سرويس گيرنده ارسال گردد.
اگر از يك سطح فني به مسئله فوق نگاه كنيم، مديريت Database Engine هاي مستقل بر روي سرويس گيرندگان بمنظور ممانعت از بروز تعارض ( Conflict ) بين دو سرويس گيرنده جهت تلاش براي دستيابي و يا بهنگام سازي برخي ركوردها مشكل است ( مسئله RecordLocking ).

مدل Two Tire

بمنظور حل مشكل مطرح شده در مدل One-tire از بعد كارائي و مسائل فني مربوطه، مدل فوق معرفي گرديد. نرم افزارهائي كه با اتكا بر مدل فوق طراحي و پياده سازي مي گردنند در اغلب موارد داراي عملكردي مشابه مدل One Tire بوده با اين تفاوت مهم كه Database Engine بر روي سرويس گيرنده ها اجرا نخواهد شد.
در مدل فوق بانك اطلاعاتي بر روي سرويس دهنده اجرا مي گردد. از روش هاي متعددي براي ارتباط بين لايه Application(Logic) و Database Service استفاده مي گردد. SQL ( زبان ساختيافته پرس و جو ) از متداولترين روش هاي موجود در اين زمينه است. دستورات SQL به سرويس دهنده بانك اطلاعاتي ارسال شده و در آنجا عمليات مربوطه بصورت محلي انجام و نتيجه ( اطلاعات مربوط به درخواست ارسال شده ) براي سرويس گيرنده ها ارسال خواهد شد. در مدل فوق صرفا سرويس دهنده بانك اطلاعاتي از برنامه مجزا شده و لايه هاي Presentation و Busines Logic همچنان در هم تنيده هستند. دو لايه فوق همچنان داراي آگاهي اساسي ( محرمانه ) از بانك اطلاعاتي خواهند بود.
نوشتن برنامه هائي از اين قبيل تا اندازه اي پيچيده تر از مدل قبل است. امروزه ابزارهاي برنامه نويسي نيز مجهز به پتانسيل هائي شده اند كه طراحي و نوشتن اين نوع از برنامه ها را سرعت مي بخشد. اغلب ابزارهاي برنامه نويسي داراي امكاناتي جهت استفاده از DataBase Engines بوده كه مي توان از آنها در طراحي برنامه هاي One-Tire استفاده كرد ( نظير Jet Engine كه توسط اكسس و ويژوال بيسيك استفاده مي گردد) اما نرم افزارهاي Two Tire نيازمند محصولات مجزاي بانك اطلاعاتي نظير Oracle , IBM DB2 , Sybase و SQL Sever مي باشند.

مدل Three Tire

اين مدل همانگونه كه احتمالا حدس زده ايد تمامي سه لايه گفته شده را در بخش هاي مستقل قرار مي دهد. در مدل فوق Business Logic يك سرويس است و مي تواند بر روي كامپيوتر اختصاصي خود فعال و اجرا گردد. زمانيكه Business بصورت يك سرويس دهنده در نظر گرفته مي شود با نام Application Server ناميده مي شود. يك Application Server اغلب ممكن است بر روي همان كامپيوتري كه DataBase Engine قرار دارد، نصب گردد. شايد يكي از دلايل مهم جهت انجام اين كار افزايش كارآئي سيستم باشد.
يكي از مزاياي مهم و كليدي، داشتن يك Application Server اين است كه بتوان آن را در محلي قرار داد كه به بهترين نوع ممكن خدمات خود را ارائه نمايد. در اين مدل مسئله حائز اهميت در اين است كه تمامي Application Serverها بتوانند و مي بايست سرويس بانك اطلاعاتي خود را از يك كامپيوتر مركزي دريافت دارند. ( ممكن است در برخي حالات تعدادي از كاربران نرم افزار از يك Application Server كه بر روي يك كامپيوتر مجزا قرار گرفته است استفاده نمايند و يك كاربر از راه دور ممكن است ApplicationServer را بر روي يكدستگاه كامپيوتر اختصاصي اجرا نمايد.) بهرحال محل ApplicationServer و Database Server ارتباطي با كاربر نداشته و تمامي آنها با يك روش يكسان از نرم افزار و توانائي آن استفاده مي نمايند.
در مدل فوق لايه Presentation داراي آگاهي خصوصي از بانك اطلاعاتي نبوده و لايه فوق از طريق لايه Application Server و بكمك يك استراتژي خاص با بانك اطلاعاتي مرتبط خواهد بود. مرورگرها در حالت خاص داراي هيچگونه شناختي از ساختار بانك اطلاعاتي در سايت Amazon.comنمي باشند ولي با اين حال قادر به ارتباط با بانك اطلاعاتي و خريد يك كتاب هستند. در مدل فوق با نگرش وب، سرويس گيرنده از طريق يك پروتكل خاص با يك Application Server مرتبط مي گردد. برنامه هائي از اين نوع ( مدل Three Tire ) پيچيده تر از مدل هاي قبلي بوده و هنوز ابزارهاي برنامه نويسي خاصي در اين زمينه وجود ندارد و برنامه نويسان مجبور به نوشتن حجم بالائي از كدها خواهند بود.

مدل N Tire

اين مدل امروزه بسرعت رايج و مطرح شده است. در حقيقت مدل ThreeTire در حالت خاص به سمت N-Tire ميل خواهد كرد. در اين حالت يك Application Server مي تواند درخواست خود را از چندين سرويس ديگر داشته باشد. هر يك از سرويس هاي صدا زده شده نيز خود مي توانند سرويس هاي ديگري را جهت پاسخگوئي به درخواست واصل شده، فعال نمايند. واژه MiddleWare اغلب جهت تشريح ارتباط يك برنامه يا Business Logic بر روي يك Application Server استفاده مي گردد.

چه ميزان از Bussines Logic مي بايست بر روي Application Server قرار گيرد؟

بدون شك يكي از بخش هاي مهم هر نرم افزار كه دائما مي تواند دستخوش تغييرات گردد، مجموعه قوانيني است كه با اعمال آنها سياست عملكردي يك نرم افزار تعيين مي گردد. مثلا در يك سيستم بازرگاني مي توان قانوني را داشته باشيم كه براي خريدهاي بالاي يكصد هزار تومان مجوز مدير مربوطه فرض است. در اين حالت مي توان قانون فوق را بصورت يك روتين ( سرويس ) و بصورت جامع طراحي و در لايه Application قرار داد، سرويس فوق مي تواند توسط ساير سرويس هاي موجود در اين لايه و يا ساير لايه ها مورد استفاده قرار گيرد. بديهي است در صورتيكه اين سياست به نوعي تغيير نمايد و قرار شود از اين پس خريدهاي بالاي يكصد و پنجاه هزار تومان مكلف به تاييد مديريت مربوطه باشند، بسادگي با اعمال تغيير در روتين فوق و تزريق سياست جديد، زمينه استفاده اتوماتيك از آن براي ساير سرويس هاي استفاده كننده فراهم مي گردد.
نحوه و زمان تغيير سياست فوق از ديدگاه استفاده كننده و لايه Presentation مهم نبوده و تغييرات بصورت خودكار در تمامي سرويس هاي موجود در ساير لايه ها حس خواهد شد. بنابراين مجموعه قوانين و سياست هائي كه در روند عملياتي يك نرم افزار نقش تعيين كننده اي را دارند، مي بايست در لايه Application قرار گرفته تا بدينوسيله امكان درج تغييرات و اعمال سياست هاي جديد مركزيت يافته و مسائل مربوط به پشتيباني و ارتقا يك نرم افزار با اطمينان خاطر و صرف كمترين زمان و هزينه صورت پذيرد.
در برخي از موارد مي توان اين سياست ها را در قالب مجموعه اي از سرويس ها در لايه Presentation قرار داد. بررسي صحت داده هاي ورودي يك نمونه مناسب در اين زمينه است. در اين مورد اغلب قوانين جهت بررسي اعتبار و صحت داده هاي ورودي بر روي لايه Presentation قرار خواهد گرفت. بديهي است در چنين حالتي بجاي ارسال اطلاعات بررسي نشده به لايه Application و بكارگيري يك روتين جهت بررسي صحت داده ها، مي توان اين عمليات را در لايه Presentation قرار داد تا بدينوسيله از يكطرف ترافيك محيط انتقال داده ها افزايش نيابد و از طرف ديگر كاربران رودرو با لايه Presentation بازخوردهاي سريعي را از سيستم داشته باشند. بهرحال در چنين حالاتي بخشي از منطق عملكرد يك نرم افزار را در لايه Presentation قرار داده ايم. در صورتيكه حجم Logic اضافه شده در لايه Presentation كم و ناچيز باشد، در اينصورت لايه فوق بصورت انحصاري مسئوليت هاي پيش فرض خود را دنبال خواهد كرد. در چنين وضعيتي سرويس گيرنده را Thin Client مي گويند. در حالتيكه بر روي سرويس گيرنده، Logic بالائي قرار گرفته باشد، به آن FatClient مي گويند.بهترين نمونه از يك Thin Client، مرورگرهاي وب بوده كه قادر به ارتباط با انواع نرم افزهائي است كه بر روي وب سايت قرار دارند.

جمع بندي

واژه Client Server داراي معاني بمراتب بيشتري نسبت به جداسازي يك كامپيوتر سرويس گيرنده و سرويس دهنده از يكديگر است واژه فوق بسرعت در دنياي نرم افزار نيز مطرح و داراي جايگاه ويژه اي در اين زمينه شده است. از ديدگاه فوق يك روتين ( سرويس ) مي تواند ارائه دهنده خدمات خاصي به ساير سرويس ها باشد. در چنين وضعيتي سرويس ارائه دهنده خدمات را Server و سرويس استفاده كننده از يك خدمات را Client مي گويند. با تعميم سياست هاي طراحي نرم افزار از مدل هاي One Tire به Two-Tire و Three Tire و نهايتا N-Tire و تاكيد بر نگرش ساختيافته و اصولي به عملكرد هر يک از لايه ها، مفهوم روتين هاي سرويس دهنده ( Server ) و روتين هاي سرويس گيرنده (Client) جايگاه ممتازي را پيدا نمودند.
يك سرويس مي تواند در عين خدمات دهي به ساير سرويس هاي متقاضي، خود نيز از خدمات ساير سرويس ها استفاده نمايد. بنابراين يك سرويس دهنده در چنين حالتي بصورت اختصاصي صرفا رسالت سرويس دهي و يا سرويس گيري را انجام نخواهد داد. اگر از ديگاه هر لايه به عملكرد سرويس ها نظري داشته باشيم، قطعا تمامي آنها مسئوليت ارائه يك سرويس خاص را در لايه مربوطه برعهده خواهند داشته و قدرمطلق تمامي آنها ارائه خدمات است. مهمترين مزيت نگرش فوق حركت بi سمت توليد سرويس هائي خواهد بود كه اولا امكان استفاده از آنان در چندين نرم افزار فراهم شده و ثانيا زمينه تحقق اصل بسيار مهم استفاده مجدد از كدهاي نوشته شده (Reusable Code) نيز فراهم مي گردد. امروزه با توجه به نياز روزافزون به طراحي و پياده سازي نرم افزارهاي متكي بر وب، مدل هاي Three Tire و N-Tire بشدت مورد توجه طراحان و پياده كنندگان نرم افزارهاي متكي بر بستر وب قرار گرفته است.
* ارسال مقاله توسط عضو محترم سايت با نام کاربري : mirkazemi
/خ