ARC ને ઊંડાણથી સમજાવો: weak vs unowned, અને leak કેવી રીતે શોધવા.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** class instance માટે memory ને compile time પર strong reference track કરીને manage કરે છે: compiler `retain`/`release` call insert કરે છે, અને જ્યારે object ની strong count શૂન્ય થાય ત્યારે તે તરત deallocate થાય છે — deterministically, background garbage collector દ્વારા નહીં.

## reference count ને કેવી રીતે અસર કરે છે

- **strong** (default) — count વધારે છે; object ને જીવંત રાખે છે.
- **weak** — count *નથી* વધારતું; deallocation પર આપોઆપ `nil` set થાય છે. `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 vs unowned — નિર્ણય

આદત થી નહીં, **lifetime સંબંધ** થી પસંદ કરો:

| | weak | unowned |
|--|------|---------|
| Optional | હા (nil બને) | નહીં |
| ARC cost | થોડું વધારે (tracked) | ઓછું |
| બીજું object ગયું હોય તો સુરક્ષિત | હા | **crash** |
| ક્યારે વાપરવું | reference *યથાર્થ* રીતે nil બની શકે (delegate, parent જે પહેલા deallocate થઈ શકે) | reference self કરતાં વધુ જીવવાની ખાતરી હોય (child → ફરજિયાત parent) |

## Leak શોધવા

1. **Xcode Memory Graph Debugger** — pause કરો અને એવા object શોધો જે ગયા હોવા જોઈએ; જાંબલી `!` marker cycle ને ધ્વજિત કરે છે.
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 closure, બે-માર્ગી parent/child strong reference, પોતાના target ને retain કરતા `Timer`/`DispatchSourceTimer`, અને deallocate થાય તેવા cancellable માં ન સંગ્રહાયેલા Combine subscription.

## આ શા માટે મહત્વનું છે

ARC deterministic છે, તેથી leak એ તમારી જવાબદારી છે, GC ની નહીં — એક જ retain થયેલો view controller megabyte જેટલી image અને તેનો આખો object graph pin કરી શકે છે. Senior interview આ ચકાસે છે કારણ કે weak vs unowned યોગ્ય રીતે પસંદ કરવું અને memory graph થી leak *સાબિત* કરવો કેવી રીતે એ જ લાંબા ચાલતા app ને ફૂલી જવાથી બચાવે છે.

	weak	unowned
Optional	હા (nil બને)	નહીં
ARC cost	થોડું વધારે (tracked)	ઓછું
બીજું object ગયું હોય તો સુરક્ષિત	હા	crash
ક્યારે વાપરવું	reference યથાર્થ રીતે nil બની શકે (delegate, parent જે પહેલા deallocate થઈ શકે)	reference self કરતાં વધુ જીવવાની ખાતરી હોય (child → ફરજિયાત parent)

reference count ને કેવી રીતે અસર કરે છે

weak vs unowned — નિર્ણય

Leak શોધવા

સામાન્ય leak ના સ્રોત

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો