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 डालता है, और जब किसी 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 जाने पर safe | हाँ | **crash** |
| कब उपयोग करें | reference वैध रूप से nil बन *सकता* है (delegates, ऐसा parent जो पहले deallocate हो सकता है) | reference का self से अधिक जीवित रहना सुनिश्चित है (child → अनिवार्य parent) |

## leaks का पता लगाना

1. **Xcode Memory Graph Debugger** — रुककर उन objects को देखें जिन्हें चले जाना चाहिए था; बैंगनी `!` markers cycles को flag करते हैं।
2. **Instruments → Leaks / Allocations** — एक flow दोहराते समय monotonically बढ़ती memory पर नजर रखें।
3. **`deinit` logging** — सबसे तेज sanity check: यदi किसी 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`, और ऐसी Combine subscriptions जो deallocate होने वाले cancellable में store नहीं की गईं।

## यह क्यों महत्वपूर्ण है

ARC deterministic है, इसलिए leaks किसी GC की नहीं, बल्कि आपकी जिम्मेदारी हैं — एक भी retained view controller megabytes की images और उसके पूरे object graph को pin कर सकता है। Senior interviews इसकी पड़ताल करते हैं क्योंकि weak बनाम unowned को सही ढंग से चुनना और memory graph के साथ एक leak को *सिद्ध* करना जानना ही long-running apps को फूलने से बचाता है।

	weak	unowned
Optional	हाँ (nil बन जाता है)	नहीं
ARC cost	थोड़ा अधिक (tracked)	कम
दूसरा object जाने पर safe	हाँ	crash
कब उपयोग करें	reference वैध रूप से nil बन सकता है (delegates, ऐसा parent जो पहले deallocate हो सकता है)	reference का self से अधिक जीवित रहना सुनिश्चित है (child → अनिवार्य parent)

references count को कैसे प्रभावित करते हैं

weak बनाम unowned — निर्णय

leaks का पता लगाना

आम leak के स्रोत

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न