Mutasd be az ARC-ot mélységében: weak vs unowned, és hogyan észleld a szivárgásokat.

Question

IT Interview Practice · Accepted Answer

Az **ARC (Automatic Reference Counting)** az osztálypéldányok memóriáját kezeli azáltal, hogy fordítási időben követi a strong referenciákat: a fordító `retain`/`release` hívásokat szúr be, és amikor egy objektum strong számlálója eléri a nullát, azonnal felszabadul — determinisztikusan, nem egy háttérben futó szemétgyűjtő által.

## Hogyan hatnak a referenciák a számlálóra

- **strong** (alapértelmezett) — növeli a számlálót; életben tartja az objektumot.
- **weak** — *nem* növeli; a felszabadításkor automatikusan `nil`-re állítódik. `var`-nak és optionalnak kell lennie.
- **unowned** — *nem* növeli; feltételezetten mindig érvényes. A felszabadítás utáni hozzáférés összeomlás (vagy még rosszabb, nem definiált viselkedés az `unowned(unsafe)` esetén).

```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 — a döntés

Az **élettartam-kapcsolat** alapján válassz, ne megszokásból:

| | weak | unowned |
|--|------|---------|
| Optional | igen (nil lesz) | nem |
| ARC-költség | kissé magasabb (követett) | alacsonyabb |
| Biztonságos, ha a másik objektum megszűnt | igen | **összeomlás** |
| Használd, ha | a referencia jogosan *válhat* nil-lé (delegate-ek, olyan szülő, amely előbb felszabadulhat) | garantált, hogy a referencia túléli a self-et (gyerek → kötelező szülő) |

## Szivárgások észlelése

1. **Xcode Memory Graph Debugger** — állítsd meg, és keress olyan objektumokat, amelyeknek már meg kellett volna szűnniük; a lila `!` jelölések a ciklusokat jelzik.
2. **Instruments → Leaks / Allocations** — figyeld a monoton növekvő memóriát, miközben ismételsz egy folyamatot.
3. **`deinit` naplózás** — a leggyorsabb ellenőrzés: ha a `deinit` soha nem ír ki semmit egy képernyő bezárásakor, az az objektum kiszivárgott.

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

## Gyakori szivárgásforrások

A `self`-et elfogó escaping closure-ök, a kétirányú szülő/gyerek strong referenciák, a célpontjukat megtartó `Timer`/`DispatchSourceTimer`, valamint az olyan Combine feliratkozások, amelyek nincsenek egy felszabaduló cancellable-ben tárolva.

## Miért fontos

Az ARC determinisztikus, így a szivárgások a te felelősséged, nem egy szemétgyűjtőé — egyetlen megtartott view controller több megabájtnyi képet és annak teljes objektumgráfját foglalhatja le. A senior interjúk azért firtatják ezt, mert a weak vs unowned helyes megválasztása, és annak ismerete, hogyan *bizonyítsd* a szivárgást a memory graph-fal, tartja távol a hosszan futó alkalmazásokat a felduzzadástól.

	weak	unowned
Optional	igen (nil lesz)	nem
ARC-költség	kissé magasabb (követett)	alacsonyabb
Biztonságos, ha a másik objektum megszűnt	igen	összeomlás
Használd, ha	a referencia jogosan válhat nil-lé (delegate-ek, olyan szülő, amely előbb felszabadulhat)	garantált, hogy a referencia túléli a self-et (gyerek → kötelező szülő)

Hogyan hatnak a referenciák a számlálóra

weak vs unowned — a döntés

Szivárgások észlelése

Gyakori szivárgásforrások

Miért fontos

Kapcsolódó kérdések