ARC ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਾਓ: weak ਬਨਾਮ unowned, ਅਤੇ leaks ਕਿਵੇਂ ਪਤਾ ਲਗਾਈਏ।

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** compile time 'ਤੇ strong references ਨੂੰ track ਕਰਕੇ class instances ਲਈ memory ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੀ ਹੈ: compiler `retain`/`release` calls insert ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕਿਸੇ object ਦਾ strong count ਸਿਫ਼ਰ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਤੁਰੰਤ deallocate ਹੋ ਜਾਂਦਾ ਹੈ — deterministically, ਨਾ ਕਿ ਕਿਸੇ background garbage collector ਦੁਆਰਾ।

## References count ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ

- **strong** (default) — count ਵਧਾਉਂਦਾ ਹੈ; object ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖਦਾ ਹੈ।
- **weak** — count ਨਹੀਂ ਵਧਾਉਂਦਾ; deallocation 'ਤੇ ਆਪਣੇ-ਆਪ `nil` ਸੈੱਟ ਹੋ ਜਾਂਦਾ ਹੈ। `var` ਅਤੇ optional ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ।
- **unowned** — count ਨਹੀਂ ਵਧਾਉਂਦਾ; ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਹਮੇਸ਼ਾ valid ਹੈ। deallocation ਤੋਂ ਬਾਅਦ access ਕਰਨਾ crash ਹੈ (ਜਾਂ `unowned(unsafe)` ਨਾਲ ਇਸ ਤੋਂ ਵੀ ਬੁਰਾ, undefined behavior)।

```swift
final class Customer {
    var card: Card?                 // strong: customer owns card
}
final class Card {
    unowned let owner: Customer     // unowned: card never outlives its owner
    init(owner: Customer) { self.owner = owner }
}
```

## weak ਬਨਾਮ unowned — ਫ਼ੈਸਲਾ

**lifetime relationship** ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ, ਆਦਤ ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ:

| | weak | unowned |
|--|------|---------|
| Optional | ਹਾਂ (nil ਬਣ ਜਾਂਦਾ) | ਨਹੀਂ |
| ARC cost | ਥੋੜ੍ਹਾ ਵੱਧ (tracked) | ਘੱਟ |
| ਦੂਜਾ object ਜਾਣ 'ਤੇ ਸੁਰੱਖਿਅਤ | ਹਾਂ | **crash** |
| ਕਦੋਂ ਵਰਤਣਾ | reference *legitimately* nil ਬਣ ਸਕਦਾ ਹੋਵੇ (delegates, parent ਜੋ ਪਹਿਲਾਂ deallocate ਹੋ ਸਕਦਾ) | reference ਦੀ self ਨਾਲੋਂ ਲੰਬੀ ਜ਼ਿੰਦਗੀ ਦੀ ਗਾਰੰਟੀ ਹੋਵੇ (child → ਲਾਜ਼ਮੀ parent) |

## Leaks ਪਤਾ ਲਗਾਉਣਾ

1. **Xcode Memory Graph Debugger** — pause ਕਰੋ ਅਤੇ ਉਹਨਾਂ objects ਨੂੰ ਲੱਭੋ ਜੋ ਜਾ ਚੁੱਕੇ ਹੋਣੇ ਚਾਹੀਦੇ ਸਨ; ਜਾਮਨੀ `!` markers cycles ਨੂੰ flag ਕਰਦੇ ਹਨ।
2. **Instruments → Leaks / Allocations** — ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ flow ਦੁਹਰਾਉਂਦੇ ਹੋ ਤਾਂ ਲਗਾਤਾਰ ਵਧਦੀ memory ਨੂੰ ਦੇਖੋ।
3. **`deinit` logging** — ਸਭ ਤੋਂ ਤੇਜ਼ sanity check: ਜੇ ਕੋਈ screen ਬੰਦ ਹੋਣ 'ਤੇ `deinit` ਕਦੇ print ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਉਹ object leak ਹੋ ਗਿਆ।

```swift
deinit { print("released \(Self.self)") }  // silence on dismiss = leak
```

## ਆਮ leak ਦੇ ਸਰੋਤ

`self` ਨੂੰ capture ਕਰਨ ਵਾਲੀਆਂ escaping closures, ਦੋ-ਪਾਸੜ parent/child strong references, ਆਪਣੇ target ਨੂੰ retain ਕਰਨ ਵਾਲੇ `Timer`/`DispatchSourceTimer`, ਅਤੇ ਅਜਿਹੀ cancellable ਵਿੱਚ store ਨਾ ਕੀਤੀਆਂ Combine subscriptions ਜੋ deallocate ਹੁੰਦੀ ਹੈ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ARC deterministic ਹੈ, ਇਸ ਲਈ leaks ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹਨ, ਕਿਸੇ GC ਦੀ ਨਹੀਂ — ਇੱਕ ਇਕੱਲਾ retained view controller megabytes images ਅਤੇ ਆਪਣੀ ਪੂਰੀ object graph ਨੂੰ ਬੰਨ੍ਹ ਸਕਦਾ ਹੈ। Senior interviews ਇਸਦੀ ਪੜਤਾਲ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ weak ਬਨਾਮ unowned ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚੁਣਨਾ ਅਤੇ memory graph ਨਾਲ leak ਨੂੰ *ਸਾਬਤ* ਕਰਨਾ ਜਾਣਨਾ ਹੀ ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀਆਂ apps ਨੂੰ ਫੁੱਲਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

	weak	unowned
Optional	ਹਾਂ (nil ਬਣ ਜਾਂਦਾ)	ਨਹੀਂ
ARC cost	ਥੋੜ੍ਹਾ ਵੱਧ (tracked)	ਘੱਟ
ਦੂਜਾ object ਜਾਣ 'ਤੇ ਸੁਰੱਖਿਅਤ	ਹਾਂ	crash
ਕਦੋਂ ਵਰਤਣਾ	reference legitimately nil ਬਣ ਸਕਦਾ ਹੋਵੇ (delegates, parent ਜੋ ਪਹਿਲਾਂ deallocate ਹੋ ਸਕਦਾ)	reference ਦੀ self ਨਾਲੋਂ ਲੰਬੀ ਜ਼ਿੰਦਗੀ ਦੀ ਗਾਰੰਟੀ ਹੋਵੇ (child → ਲਾਜ਼ਮੀ parent)

References count ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ

weak ਬਨਾਮ unowned — ਫ਼ੈਸਲਾ

Leaks ਪਤਾ ਲਗਾਉਣਾ

ਆਮ leak ਦੇ ਸਰੋਤ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ