ARC ను లోతుగా వివరించండి: weak vs unowned, మరియు leak లను ఎలా గుర్తించాలి.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** compile time లో strong reference లను ట్రాక్ చేయడం ద్వారా class instance ల కోసం memory ను నిర్వహిస్తుంది: compiler `retain`/`release` call లను insert చేస్తుంది, మరియు ఒక object యొక్క strong count సున్నాకు చేరినప్పుడు అది వెంటనే deallocate అవుతుంది — background garbage collector ద్వారా కాదు, deterministic గా.

## Reference లు count ను ఎలా ప్రభావితం చేస్తాయి

- **strong** (default) — count ను పెంచుతుంది; object ను సజీవంగా ఉంచుతుంది.
- **weak** — count ను పెంచదు; deallocation లో దానంతటదే `nil` కు set అవుతుంది. తప్పనిసరిగా `var` మరియు optional అయి ఉండాలి.
- **unowned** — count ను పెంచదు; ఎల్లప్పుడూ చెల్లుబాటు అవుతుందని భావించబడుతుంది. 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 relationship** ద్వారా ఎంచుకోండి:

| | weak | unowned |
|--|------|---------|
| Optional | అవును (nil అవుతుంది) | కాదు |
| ARC cost | కొంచెం ఎక్కువ (tracked) | తక్కువ |
| ఇతర object పోయినా సురక్షితం | అవును | **crash** |
| ఎప్పుడు వాడాలి | reference *చట్టబద్ధంగా* nil కావచ్చు (delegate లు, ముందుగా deallocate కావచ్చే parent) | reference self కంటే ఎక్కువ కాలం జీవిస్తుందని హామీ (child → తప్పనిసరి parent) |

## Leak లను గుర్తించడం

1. **Xcode Memory Graph Debugger** — pause చేసి పోయి ఉండాల్సిన object ల కోసం చూడండి; ఊదా `!` marker లు cycle లను flag చేస్తాయి.
2. **Instruments → Leaks / Allocations** — ఒక flow ను పునరావృతం చేసేటప్పుడు monotonic గా పెరుగుతున్న 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 లు, two-way parent/child strong reference లు, తమ target ను retain చేసే `Timer`/`DispatchSourceTimer`, మరియు deallocate అయ్యే cancellable లో store చేయని Combine subscription లు.

## ఇది ఎందుకు ముఖ్యం

ARC deterministic, కాబట్టి leak లు GC యొక్క కాదు, మీ బాధ్యత — ఒక్క retained view controller megabyte ల image లను మరియు దాని మొత్తం object graph ను pin చేయగలదు. weak vs unowned ను సరిగ్గా ఎంచుకోవడం మరియు memory graph తో leak ను ఎలా *నిరూపించాలో* తెలుసుకోవడం దీర్ఘకాలం run అయ్యే app లను ఉబ్బకుండా ఉంచుతుంది కాబట్టి senior interview లు దీన్ని probe చేస్తాయి.

	weak	unowned
Optional	అవును (nil అవుతుంది)	కాదు
ARC cost	కొంచెం ఎక్కువ (tracked)	తక్కువ
ఇతర object పోయినా సురక్షితం	అవును	crash
ఎప్పుడు వాడాలి	reference చట్టబద్ధంగా nil కావచ్చు (delegate లు, ముందుగా deallocate కావచ్చే parent)	reference self కంటే ఎక్కువ కాలం జీవిస్తుందని హామీ (child → తప్పనిసరి parent)

Reference లు count ను ఎలా ప్రభావితం చేస్తాయి

weak vs unowned — నిర్ణయం

Leak లను గుర్తించడం

సాధారణ leak మూలాలు

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు