ARC सखोलपणे समजावून सांगा: weak वि. unowned, आणि leaks कसे शोधावे.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** class instances साठी memory manage करते, compile time ला strong references ट्रॅक करून: 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 गेल्यास सुरक्षित | होय | **crash** |
| केव्हा वापरावे | reference *वैध रीत्या* nil बनू शकते (delegates, आधी deallocate होऊ शकणारा parent) | reference self पेक्षा जास्त जगण्याची हमी (child → अनिवार्य parent) |

## Leaks शोधणे

1. **Xcode Memory Graph Debugger** — pause करा आणि जे गेले असावेत असे objects शोधा; purple `!` markers cycles दर्शवतात.
2. **Instruments → Leaks / Allocations** — एखादा flow पुन्हा करताना monotonically वाढणारी 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`, आणि deallocate होणाऱ्या cancellable मध्ये store न केलेल्या Combine subscriptions.

## हे का महत्त्वाचे आहे

ARC deterministic आहे, त्यामुळे leaks ही तुमची जबाबदारी आहे, GC ची नव्हे — एकच retain झालेला view controller megabytes images आणि त्याचा संपूर्ण object graph pin करू शकतो. Senior मुलाखती हे तपासतात कारण weak वि. unowned योग्यरित्या निवडणे आणि memory graph ने leak *सिद्ध* करणे हेच long-running apps ना फुगण्यापासून वाचवते.

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

References count वर कसा परिणाम करतात

weak वि. unowned — निर्णय

Leaks शोधणे

सामान्य leak स्रोत

हे का महत्त्वाचे आहे

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