نوشته های mina mohammadi

بررسی سه الگو معماری نرم افزار Hexagonal، Onion و Clean

mina mohammadi — Fri, 15 Dec 2023 13:08:07 +0330

روش های مختلفی برای طراحی سیستم در مهندسی نرم افزار وجود دارد و هر طراحی محاسن و چالش های خاص خود را دارد. گاهی اوقات رویکردهای مختلف طراحی سعی در دستیابی به اهداف مشابه دارند. وقتی به طراحی معماری نرم افزار فکر می کنیم، به خصوص در دنیای شی گرا، سه الگوی که بیشتر در مورد آنها صحبت می شود عبارتند از: معماری Clean، معماری Hexagonal و معماری Onion.وقتی این الگوها را مشاهده می‌کنم، احساس می‌کنم که هر سه الگو سعی در طرفداری از ایده‌های مشابه دارند. همه این الگوها از نوع layered architecture هستند. همه آنها یک سیستم آزمایش پذیرِ loosely coupled را تعریف می کنند که از هر گونه وابستگی مستقیم از نظر پیاده سازی اجتناب می کند، اما این کار را با استفاده از اصطلاحات خاص خود و هر کدام با تفاوت های ظریف خاص انجام می دهند. همه آنها رویکردهایی را برای مدیریت پذیرتر و آزمایش پذیرتر کردن معماری نرم افزار پیشنهاد می کنند، اما این کار را به روش خود انجام می دهند.اگر همه آنها را با هم نگاه کنیم، برخی از نکات مفید معماری را ارائه می دهند که صرف نظر از رویکرد طراحی که انتخاب می کنید قابل اجرا هستند. ما به زودی آنها را بررسی خواهیم کرد، اما ابتدا اجازه دهید نگاهی به هر یک از این الگوها به صورت جداگانه و مقایسه آنها با یکدیگر بیندازیم.معماری Hexagonalمعماری شش ضلعی گاهی اوقات به عنوان معماری پورت ها و آداپتورها نیز شناخته می شود. آلیستر کاکبرن آن را در سال 2005 معرفی کرد و ایده اصلی آن این بود که برنامه ها مستقل از وابستگی مستقیم به رابط کاربری و پایگاه داده باشد. این جداسازی از طریق مفهوم پورت ها و آداپتورها پشتیبانی می شود.بیایید یک مثال بزنیم. به عنوان یک توسعه دهنده، شما باید یک business logic مرتبط با کاربر را طراحی کنید، که در پایگاه داده باقی بماند. هدف این است که هر کدام از business logic و persistence ایزوله باشند تا هر دو بتوانند مسئولیت های اصلی خود را انجام دهند و رشد کنند. برای این هدف انجام اقدامات زیر لازم است:یک منطق مختص پایگاه داده در یک کلاس آداپتور قرار می گیرد، به عنوان مثال، UserDataAdapterکلاس business logic مختص کاربر، مانند Userقراردادی بین User و UserDataAdapter به طوری که آنها بتوانند با یکدیگر تعامل داشته باشند - به عنوان مثال: IUserDataPort. این قرارداد یک پورت است.همانطور که کاکبرن توضیح می دهد، کلمه "hexagon" به این دلیل انتخاب نشده است که عدد شش مهم است، بلکه به افرادی که معماری را طراحی می کنند اجازه می دهد تا فضای کافی برای قرار دادن پورت ها و آداپتورها در صورت لزوم داشته باشند و اطمینان حاصل شود که آنها توسط یک طراحی لایه ای یک بعدی محدود نمی شوند.برای مشاهده تمپلیت معماری Hexagonal اینجا کلیک کنید.معماری Onionجفری پالرمو مفهوم معماری Onion را در سال 2008 معرفی کرد. او می خواست با تأکید بر separation of concerns در سراسر سیستم، یک رویکرد طراحی برای نرم افزارهای تجاری پیچیده ایجاد کند. این الگو گام‌های مهمی فراتر از معماری Hexagonal برداشت زیرا ایده تعریف لایه Core Business در یک برنامه کاربردی و لایه‌های مختلف اطراف آن را گسترش داد، به طوری که لایه هسته مستقل از لایه‌های بیرونی و وابستگی‌های آن‌ها است.لایه مرکزی - domain model - شامل تمام قوانین کسب و کار است. در سطح بعدی domain services ها قرار دارند که مانند قراردادهای repository و سایر وابستگی ها هستند. خارجی ترین لایه شامل رابط کاربری و اتصال به زیرساخت خارجی است.به طور خلاصه، تفاوت اصلی بین معماری Onion و معماری Hexagonal این است که معماری Onion لایه‌های مختلفی را به همراه لایه کسب و کار اصلی (core business) در برنامه معرفی می‌کند و اتصالات را به وابستگی‌های خارجی مانند پایگاه‌های داده و UI به دایره بیرونی منتقل می‌کند. این بدان معناست که در صورت نیاز می توان آنها را به راحتی تعویض کرد.برای مشاهده تمپلیت معماری Onion اینجا کلیک کنید.معماری Cleanرابرت مارتین Clean Architecture را در سال 2012 معرفی کرد. مفاهیم اصلی مشابه معماری Onion است، اما اصطلاحات آن کمی متفاوت است. در اینجا، domain model به عنوان یک "موجودیت" شناخته می شود. موجودیت شامل قوانین و منطق مختص کسب و کار است، در حالی که منطق مختص عملیات برنامه کاربردی در use case قرار می گیرد. این use case، عملیات را در بالای موجودیت ها می چیند تا آنها را به اجرای قوانین کسب و کار خود برای دستیابی به اهداف use case هدایت کند.در نگاه اول، معماری Clean درک بهتری از مرزها و تفکیک واضح تری از concernها را در مقایسه با معماری Onion ارائه می دهد. آنها بسیار نزدیک به هم مرتبط هستند و از ایده های مشابه، اما با لایه های مختلف طرفداری می کنند. معماری Clean به طور مشخص دلیل وجود هر لایه و وظایف مربوط به آنها را مشخص می کند. به همین دلیل است که به Screaming architecture نیز معروف است - همه چیز را واضح می کند.برای مشاهده تمپلیت معماری Clean اینجا کلیک کنید.الگوهای معماری به ما چه می آموزند؟همانطور که دیدیم، هر سه سبک معماری اصول loose coupling را به اشتراک می گذارند و سعی می کنند با لایه بندی مناسب برنامه، قطعات متحرک را به حداقل برسانند.بنابراین، نکات کلیدی که این سه الگو به ما ارائه می دهند چیست؟ چه اصول اساسی معماری را باید در نظر داشته باشیم؟مرکزیت قوانین کسب و کارقرار دادن قوانین کسب و کار در یک مکان متمرکز چیزی است که هم توسط معماری Clean و هم معماری Onion پیشنهاد شده است. اگرچه آنها از نام‌های متفاوتی برای مفاهیم بسیار مشابه استفاده می‌کنند، اما هر دو ما را تشویق می‌کنند که در مورد منطق کسب و کار به یک روش فکر کنیم.قوانین برنامه کاربردی (Application Rules)باز هم، هر دو معماری Clean و Onion به جهت های مشابهی اشاره می کنند. آنها پیشنهاد می‌کنند که باید لایه‌ای وجود داشته باشد که در آن منطق خاص برنامه کاربردی را در کنار قوانین کسب و کار مدیریت کنید.این لایه شامل ترتیب عملیات و منطق مربوط به برنامه کاربردی خواهد بود.قانون وابستگیهر سه الگو بر اساس این اصل هماهنگ هستند که تاکید می کند که وابستگی های source code فقط باید به سمت داخل باشد. لایه بیرونی فقط می تواند به لایه داخلی اشاره داشته باشد و نه برعکس.جداسازی بین لایه های مختلفهر سه الگو قویاً از این امر حمایت می کنند که بخش های مختلف برنامه باید بتوانند به صورت ایزوله و جداگانه با یکدیگر رشد کنند و باید انتزاع مناسبی بین هر لایه از برنامه وجود داشته باشد.مهمتر از همه، قوانین اصلی کسب و کار باید مستقل از موارد زیر باشد:چگونه آن را ذخیره می کنید:انتخاب پایگاه داده شما نباید بر دامنه اصلی تأثیر بگذارد.اگر نوع پایگاه داده را تغییر دهید، به عنوان مثال: از SQL به NoSQL، نباید هیچ تغییری در منطق کسب و کار شما ایجاد شود.تعامل بین دامنه و persistence از یک استاندارد تعریف شده پیروی می کند و مستقل از جزئیات persistence خواهد بود.چگونه آن را نمایش می کنید:منطق UI و use case ها هرگز نباید شما را به تغییر دامنه اصلی ترغیب کند.چه آن را از طریق JSON، XML یا GraphQL نمایش دهید، core نباید تحت تأثیر قرار گیرد.از کدام framework استفاده می کنید:در حالت ایده آل، دامنه اصلی باید مستقل از framework مورد استفاده باشد. این ممکن است خیلی ساده نباشد، اما می توان از طریق انتزاعات دقیق به آن دست یافت.به عنوان مثال، اگر از Springboot به Micronaut در جاوا، Zin به Martini در Golang، از WebAPI به Nancy در NETCore تغییر دهید، نباید از نظر نحوه تعریف دامنه اصلی تغییری ایجاد شود.وابستگی های خارجی شما چیست:حوزه اصلی نباید تحت تأثیر زیرساخت ها و وابستگی های مرتبط قرار گیرد. به عنوان مثال، اگر از AWS Kinesis استفاده می کنید و باید آن را با Kafka streams جایگزین کنید، دامنه اصلی به هیچ وجه نباید تحت تأثیر قرار گیرد.ایمیل، پیامک و رویدادها چند نمونه از این وابستگی ها هستند.نتیجهالگوهای معماری هسته اصلی نحوه طراحی برنامه های کاربردی ما هستند. اگرچه ممکن است الگوهای مختلفی را انتخاب کنیم، اما با شناسایی و شناخت شباهت‌های آنها، می‌توانیم از برخی اصول اساسی پیروی کنیم که پایه محکمی برای طراحی یک برنامه کاربردی کسب و کار فراهم می‌کند. درک این قوانین به من کمک کرده است تا سیستم های نرم افزاری قابل توسعه، قابل آزمایش و جامع ایجاد کنم.برگرفته ازhttps://www.thoughtworks.com/insights/blog/architecture/demystify-software-architecture-patternshttps://www.c-sharpcorner.com/article/hexagonal-architecture-in-net-c-sharp-api-development-a-comprehensive-guide/https://github.com/jasontaylordev/CleanArchitecture/tree/main/src/Domainhttps://github.com/ardalis/CleanArchitecture/tree/main/srchttps://medium.com/%40omid-ahmadpour/clean-architecture-template-with-net-and-its-importance-e5b3b97a6e48

مدیریت حافظه در Net.

mina mohammadi — Fri, 17 Nov 2023 16:10:03 +0330

در این مقاله، کارکرد Garbage Collection در Net. و طریقه بهینه سازی مدیریت حافظه در #C و را بررسی می کنیم. برای ورود به دنیای تکنیک های پیشرفته، بهترین روش ها و مثال های کاربردی که درک Garbage Collection را برای شما ساده می کند و مهارت های توسعه نرم افزار شما را بهبود می دهد آماده باشید.اهمیت مدیریت حافظه در #Cمدیریت حافظه یک جنبه حیاتی در پرفورمنس و پایداری هر برنامه ای است. مدیریت کارآمد حافظه تضمین می کند که برنامه شما به طور موثر از منابع استفاده می کند، از نشت حافظه جلوگیری می کند و احتمال خرابی یا کاهش سرعت را کاهش می دهد. در سی شارپ، مکانیسم Garbage Collection در Net. وظیفه مدیریت خودکار حافظه را بر عهده دارد و باعث تمرکز توسعه‌دهندگان بر روی نوشتن کد بدون نگرانی از مدیریت دستی حافظه می شود.مروری بر Garbage Collection در Net.درواقع، Garbage Collection، یا به اختصار (GC)، یک فیچر مدیریت حافظه است که توسط دات نت Run Time ارائه شده است که به طور خودکار حافظه را از اشیایی که دیگر استفاده نمی شوند بازیابی می کند. این به جلوگیری از نشت حافظه، بهبود پرفورمنس برنامه و به حداقل رساندن احتمال خطاهای out-of-memory کمک می کند. در این مقاله، نحوه کار GC در Net.، نحوه تعامل آن با کد سی شارپ و نحوه بهینه‌سازی عملکرد آن برای برنامه‌های خود را مورد بحث قرار خواهیم داد.درک GC در Net.بیایید با درک کاملی از چیستی و نحوه عملکرد Garbage Collection در اکوسیستم Net. شروع کنیم.اصول Garbage Collectionچگونگی کارکرد Garbage Collectionکارکرد GC در Net. بر اساس مفهوم دسترسی پذیری اشیا است. یک شی در صورتی قابل دسترسی در نظر گرفته می شود که یک ارجاع مستقیم یا غیرمستقیم از اشیاء ریشه، مانند فیلدهای استاتیک، متغیرهای محلی، یا ثبات های CPU، به آن وجود داشته باشد. GC به صورت دوره ای اشیا غیرقابل دسترس را بررسی می کند و حافظه اشغال شده توسط آنها را بازیابی می کند.{ MyClass obj = new MyClass(); // Object is created and referenced // ... obj = null; // Object is now unreachable and becomes a candidate for garbage collection }نسل ها و عملکرددرواقع، Garbage Collector دات نت از یک رویکرد نسلی برای بهبود عملکرد استفاده می کند. اشیا به سه نسل - 0، 1 و 2 - گروه بندی می شوند. اشیا جدید در ابتدا در نسل 0 قرار می گیرند. هنگامی که GC اجرا می شود، ابتدا اشیاء را از نسل 0 جمع آوری می کند. اگر یک شی از فرآیند جمع آوری زنده بماند، به نسل بعدی ارتقا می یابد. این رویکرد زمان صرف شده برای Garbage Collection را کاهش می دهد، زیرا اشیا با عمر طولانی کمتر در این فرایند جمع آوری قرار می گیرند.الگوریتم های Garbage Collectionچندین الگوریتم در Garbage Collection وجود دارد. در اینجا به سه مورد رایج می پردازیم.الگوریتم علامت گذاری و جارو کردناین الگوریتم از دو فاز تشکیل شده است:علامت گذاری: GC گراف شی را طی می کند، از اشیاء ریشه شروع می شود و همه اشیاء قابل دسترسی را علامت گذاری می کند.جارو کردن: GC حافظه را جارو می کند، اشیاء بدون علامت (غیرقابل دسترسی) را حذف می کند و حافظه را آزاد می کند.الگوریتم کپیالگوریتم کپی حافظه را به دو نیمه مساوی تقسیم می کند. هنگامی که یک شی تخصیص داده می شود، در نیمی از حافظه قرار می گیرد. در طول Garbage Collection، اشیا قابل دسترسی در نیمه دیگر کپی می شوند و نیمه اصلی پاک می شود و حافظه آزاد می شود.الگوریتم نسلی (Generational)همانطور که قبلا ذکر شد، الگوریتم Generational اشیا را بر اساس سن آنها به نسل ها گروه بندی می کند. GC ابتدا جوان ترین نسل را هدف قرار می دهد و اشیایی که زنده می مانند به نسل های قدیمی تر معرفی می شوند. این رویکرد زمان Garbage Collection را با تمرکز بر اشیا تازه ایجاد شده که احتمال عدم دسترسی آنها زیاد است، کاهش می دهد.مدیریت حافظه در #Cاکنون که Garbage Collection در Net. را فهمیدیم، بیایید ببینیم که چگونه با مدل مدیریت حافظه #C ارتباط دارد.تخصیص و آزاد سازی حافظهپشته در مقابل هیپسی شارپ حافظه را در دو ناحیه مجزا مدیریت می کند: پشته و هیپ. پشته برای ذخیره value type ها، پارامترهای متدها و متغیرهای محلی استفاده می شود، در حالی که هیپ برای ذخیره reference type ها (اشیاء) استفاده می شود. Garbage Collector مسئول مدیریت حافظه در هیپ است.آشنایی با Value Type ها و Reference Type ها در واقع، value type ها (به عنوان مثال، int، float، structs) مستقیماً در پشته ذخیره می شوند، در حالی که reference type ها (به عنوان مثال، کلاس ها، آرایه ها) در هیپ ذخیره می شوند. هنگامی که یک value type را اختصاص می دهید، یک کپی از مقدار ایجاد می شود، در حالی که اختصاص یک reference type، یک مرجع جدید به همان شی ایجاد می کند.int a = 42; // Value typeint b = a; // Creates a copy of the valueb = 13; // 'a' remains unchangedMyClass objA = new MyClass(); // Reference typeMyClass objB = objA; // Creates a new reference to the same objectobjB.SomeProperty = 7; // Modifies the object shared by 'objA' and 'objB'مدیریت خودکار حافظهسی شارپ به طور خودکار تخصیص و آزادسازی حافظه را مدیریت می کند و از Garbage Collector برای مدیریت حافظه مورد استفاده توسط reference type ها استفاده می کند. به عنوان یک توسعه دهنده، لازم نیست نگران آزادسازی صریح حافظه باشید، زیرا GC آن را برای شما مدیریت می کند.اینترفیس IDisposableمدیریت منابع مدیریت نشدهدر حالی که GC به طور خودکار مدیریت حافظه را برای اشیاء مدیریت شده انجام می دهد، منابع مدیریت نشده، مانند مدیریت کننده های فایل یا اتصالات پایگاه داده را مدیریت نمی کند. برای آزادسازی صحیح این منابع، باید رابط IDisposable را پیاده سازی کنید.در واقع، IDisposable برای مدیریت حافظه منابع مدیریت نشده یا "Unmanaged Resources" است.پیاده سازی اینترفیس IDisposableبرای پیاده سازی IDisposable، باید یک متد Dispose تعریف کنید که منابع مدیریت نشده را آزاد می کند و به صورت اختیاری، نهایی سازی را برای شی متوقف می کند.توضیح تکمیلی:اگر کد سرویس گیرنده (Client)، Dispose را فراخوانی کند، پاکسازی منابع هر چند وقت یکبار انجام می شود و نیازی به انجام مجدد در طی نهایی سازی نیست. فراخوانی SuppressFinalize در این شرایط به این معنی است که شی دیگر متحمل هزینه اضافی GC نهایی سازی نمی شود.و اگر کلاس شما فقط از منابع مدیریت شده استفاده می کند، نهایی کننده کاملا غیر ضروری است: GC از هر گونه منابع مدیریت شده مراقبت می کند، اجازه دهید خود آن منابع درگیر این باشند که آیا به یک نهایی کننده مجدد نیاز دارند یا خیر. شما فقط در صورتی باید یک نهایی کننده را در کلاس خود در نظر بگیرید که مستقیماً منابع مدیریت نشده را مدیریت کند.public class MyClass : IDisposable{ private IntPtr _unmanagedResource; public MyClass() { _unmanagedResource = // Allocate unmanaged resource } public void Dispose() { ReleaseUnmanagedResource(_unmanagedResource); GC.SuppressFinalize(this); } ~MyClass() { ReleaseUnmanagedResource(_unmanagedResource); }}دستور usingدستور using به شما این امکان را می دهد که از یک شی IDisposable استفاده کنید و اطمینان حاصل می کند که متد Dispose زمانی که شی از محدوده خارج می شود فراخوانی می شود.using (MyClass obj = new MyClass()){ // Use 'obj' as needed} // 'Dispose' is automatically called when the block is exitedبهینه سازی Garbage Collection در Net.اکنون بیایید تکنیک هایی را برای بهینه سازی Garbage Collection و اطمینان از استفاده کارآمد از حافظه در برنامه های #C خود بررسی کنیم.استفاده کارآمد از حافظهادغام اشیا (استخر اشیا)ادغام اشیاء با استفاده مجدد از اشیا یک استخر، هزینه های ایجاد و تخریب مکرر اشیا را کاهش می دهد. هنگامی که یک شی مورد نیاز است، از استخر گرفته می شود و زمانی که دیگر مورد نیاز نیست، برای استفاده مجدد به استخر برگردانده می شود.public class MyObjectPool{ private readonly Stack _pool = new Stack(); public MyClass GetObject() { return _pool.Count > 0 ? _pool.Pop() : new MyClass(); } public void ReturnObject(MyClass obj) { _pool.Push(obj); }}کش کردنکش کردن تکنیکی است که نتایج عملیات گران قیمت را ذخیره می کند و در صورت نیاز مجدداً از آنها استفاده می کند و نیاز به تخصیص مکرر اشیا و آزادسازی را کاهش می دهد.public class MyCache{ private readonly Dictionary () _cache = new Dictionary();public ExpensiveObject Get(string key){ if (!_cache.TryGetValue(key, out ExpensiveObject value)) { value = new ExpensiveObject(); _cache[key] = value; } return value;}کاهش تخصیص اشیابه حداقل رساندن تخصیص اشیا می تواند به کاهش هزینه های Garbage Collection کمک کند. برخی از تکنیک ها برای رسیدن به این هدف عبارتند از:استفاده از Value Type ها (structs) به جای Reference Type ها (کلاس ها) در صورت لزوم.استفاده مجدد از اشیاء در صورت امکان، مانند استفاده از StringBuilder برای الحاق رشته ها.اجتناب از تغییر اندازه مکرر collection ها با تعیین ظرفیت اولیه.تنظیم دقیق Garbage Collectionتنظیمات GCدات نت چندین تنظیمات را ارائه می دهد که می توانند برای بهینه سازی Garbage Collection برای نیازهای خاص برنامه شما پیکربندی شوند. برای مثال، می‌توانید بین حالت‌های workstation و سرور GC یکی را انتخاب کنید یا concurrent garbage collection را فعال یا غیرفعال کنید.// Enable server GC in the app.config or web.config file امکان Forced Garbage Collectionدر برخی موارد، ممکن است بخواهید به صورت دستی Garbage Collection را فعال کنید. می توانید این کار را با استفاده از متد ()GC.Collect انجام دهید. با این حال، از این با احتیاط استفاده کنید، زیرا می تواند بر عملکرد تأثیر منفی بگذارد.// Force a garbage collection passGC.Collect();نظارت و تشخیص عملکرد GCمی توانید از شمارنده های عملکرد (performance counters) و ردیابی رویداد (event tracing) برای نظارت بر رفتار و عملکرد Garbage Collector استفاده کنید. این می تواند به شما در شناسایی مشکلات احتمالی و تنظیم دقیق تنظیمات Garbage Collection برنامه کمک کند.// Retrieve the current memory usagelong memoryUsage = GC.GetTotalMemory(false);Console.WriteLine("Memory usage: {0} bytes", memoryUsage);بهترین روش ها برای Garbage Collection در Net.بیایید بحث را با بیان برخی از بهترین روش‌ها را برای اطمینان از Garbage Collection و مدیریت حافظه کارآمددر برنامه‌های #C جمع‌بندی کنیم.نوشتن کدِ حافظه-کارآمدجلوگیری از نشت حافظهبرای جلوگیری از نشت حافظه، اطمینان حاصل کنید که:با پیاده سازی IDisposable، منابع مدیریت نشده را به درستی آزاد کنید.مدیریت کننده های رویداد را زمانی که دیگر مورد نیاز نیستند حذف کنید.از ارجاعات دایره ای و گراف اشیا بزرگ خودداری کنید.به حداقل رساندن تخصیص هیپ اشیای بزرگتخصیص اشیاء بزرگ (85000 بایت یا بزرگتر) می تواند باعث مشکلات عملکرد شود، زیرا آنها در هیپ شی بزرگ (LOH) ذخیره می شوند. برای به حداقل رساندن تخصیص LOH:از آرایه ها یا collection هایی با ظرفیت اولیه مناسب استفاده کنید.استفاده از فایل های نگاشت شده به حافظه (memory-mapped) برای ساختارهای داده بزرگ را در نظر بگیرید.استفاده صحیح از Finalizers و IDdisposableاز نهایی کننده ها (Finalizers) می توان برای آزادسازی منابع مدیریت نشده استفاده کرد، اما همچنین می توانند بر عملکرد تأثیر منفی بگذارند. از نهایی کننده ها به اندازه کافی استفاده کنید و IDisposable را در صورت لزوم پیاده سازی کنید.ابزارهای پروفایل و نظارتابزارهای مختلفی برای کمک به نمایه کردن و نظارت بر میزان مصرف حافظه برنامه و عملکرد Garbage Collection در دسترس هستند:شمارنده های عملکردمانیتور عملکرد ویندوز (PerfMon) چندین شمارنده عملکرد مرتبط با garbage collection، مانند «% زمان در GC» و «Gen 0 Collections/sec» ارائه می‌کند.ابزارهای تشخیصی ویژوال استودیوویژوال استودیو شامل ابزارهای تشخیصی داخلی است، مانند ابزار استفاده از حافظه، که می‌تواند به شما در تجزیه و تحلیل میزان مصرف حافظه برنامه و رفتار Garbage Collection کمک کند.ابزارهای شخص ثالثچندین ابزار شخص ثالث برای نمایه سازی و نظارت بر برنامه های Net. وجود دارد، مانند JetBrains dotMemory و Redgate ANTS Memory Profiler.نتیجهدر این مقاله، کارکردهای درونی Garbage Collection در دات‌نت را بررسی کردیم، مدل مدیریت حافظه #C را بررسی کردیم و تکنیک‌هایی را برای بهینه‌سازی عملکرد Garbage Collection به اشتراک گذاشتیم. با پیروی از بهترین شیوه ها و نکات ذکر شده در اینجا، می توانید از مدیریت کارآمد حافظه در برنامه های #C خود اطمینان حاصل کنید و برنامه هایی با کارایی بالا و قوی ایجاد کنید.کد نویسی مبارک!برگرفته ازhttps://www.bytehide.com/blog/garbage-collection-dotnet