.NET میں میموری کی تدبیر اور گاربج کلیکشن کیسے کام کرتی ہے؟

Question

Accepted Answer

.NET **خودکار طور پر** میموری کو **گاربج کلیکٹر (GC)** کے ذریعے منظم کرتا ہے — یہ managed heap پر آبجیکٹس allocate کرتا ہے اور وہ جو reachable نہیں رہتے ان کو reclaim کرتا ہے، تو آپ کو manually میموری free کرنی نہیں پڑتی۔ GC کو سمجھنا (generational، stack/heap کی تقسیم، اور `IDisposable`) کارکردگی اور صحیح کام کے لیے اہم ہے۔

## Stack بمقابلہ heap

```text
Stack → value types (locals), method frames; fast, automatically freed when scope ends.
Heap  → reference type objects (class instances); managed by the GC.
A reference variable lives on the stack but points to its object on the heap.
```

## Generational garbage collector

```text
The GC divides the heap into GENERATIONS (based on the "most objects die young" idea):
  Gen 0 → newest objects; collected FREQUENTLY (fast, cheap)
  Gen 1 → survived one collection
  Gen 2 → long-lived objects; collected RARELY (expensive)
  (+ Large Object Heap for big objects)
→ Collecting young generations often + old ones rarely makes the GC efficient.
```

GC reachable objects کو mark کرتا ہے (roots سے: stack، static fields) اور باقی کو reclaim کرتا ہے۔ یہ **generational** ہے — زیادہ تر آبجیکٹس جلد مر جاتے ہیں، تو Gen 0 اکثر اور سستے انداز میں collect ہوتا ہے، جبکہ Gen 2 میں long-lived objects کم بار collect ہوتے ہیں۔

## IDisposable اور using — unmanaged resources کے لیے

```csharp
// the GC handles MANAGED memory, but NOT unmanaged resources (files, connections, handles)
// → implement IDisposable and use `using` for deterministic cleanup
using (var file = new StreamReader("data.txt"))
{
    // use file
}   // file.Dispose() called automatically — releases the file handle NOW
```

GC managed میموری کو free کرتا ہے، لیکن **unmanaged resources** (file handles، DB connections، sockets) کو explicit cleanup کی ضرورت ہے **`IDisposable`/`Dispose()`** کے ذریعے — `using` statement اس کو deterministically guarantee کرتا ہے (آپ GC کا انتظار نہیں کرتے)۔

## میموری leaks پھر بھی ہو سکتے ہیں

```text
The GC frees only UNREACHABLE objects. "Leaks" come from lingering references:
  ✗ static collections/caches that only grow
  ✗ un-unsubscribed event handlers (the publisher keeps subscribers alive!)
  ✗ long-lived objects holding references to short-lived ones
```

## یہ اہم کیوں ہے

.NET میموری کی تدبیر اور garbage collection کو سمجھنا performant، صحیح C# لکھنے کے لیے قیمتی senior-level علم ہے — جبکہ GC آپ کو manual میموری تدبیر سے آزاد کرتا ہے (ایک بڑا اہم فائدہ، manual `free` اور dangling pointers کو ختم کرتا ہے)، یہ سمجھنا کہ *یہ کیسے* کام کرتا ہے performance-sensitive applications کے لیے اہم ہے اور subtle bugs سے بچنے میں مدد کرتا ہے۔

**Generational GC** کو سمجھنا (Gen 0 بار بار اور سستے انداز میں collect ہوتا ہے، Gen 2 کم بار لیکن مہنگے انداز میں، اس نتیجہ کی بنیاد پر کہ زیادہ تر objects جلد مر جاتے ہیں) آپ کو allocation patterns اور GC pressure کے بارے میں سوچنے میں مدد کرتا ہے (allocations میں کمی، خاص طور پر short-lived objects کی، GC overhead کم کرتا ہے)۔

**Stack بمقابلہ heap** کی تفریق (value types stack پر، reference objects heap پر) value/reference type model سے جڑتی ہے۔

سب سے اہم بات، **`IDisposable`/`Dispose()` اور `using` statement** کو سمجھنا ضروری اور عملی ہے: GC *میموری* کو manage کرتا ہے لیکن *unmanaged resources* نہیں (file handles، database connections، sockets)، جنہیں `using` کے ذریعے deterministic cleanup کی ضرورت ہے — ان کو dispose نہ کرنا resource leaks کا سبب بنتا ہے (ایک عام اصل bug)۔

اتنا ہی اہم یہ سمجھنا ہے کہ **میموری leaks پھر بھی ہوتے ہیں** GC کے باوجود، lingering references سے (growing static caches، un-unsubscribed event handlers جو subscribers کو زندہ رکھتے ہیں — ایک classic C# leak)۔

GC کے generational model، resource-disposal pattern (`IDisposable`/`using`)، اور leaks کی وجوہات کو سمجھنا performant، leak-free C# لکھنے کے لیے اہم ہے، خاص طور پر long-running applications میں — یہ اسے قیمتی علم بناتا ہے جو وہ developers کو الگ کرتا ہے جو efficient، صحیح .NET applications بنا سکتے ہیں اور ایک عام senior-level interview موضوع ہے۔