ARCを深く説明してください: weak と unowned、そしてリークの検出方法。

Question

IT Interview Practice · Accepted Answer

**ARC（Automatic Reference Counting）** は、強参照をコンパイル時に追跡することでクラスインスタンスのメモリを管理します。コンパイラが `retain`/`release` 呼び出しを挿入し、オブジェクトの強参照カウントがゼロに達すると、それは即座に解放されます。バックグラウンドのガベージコレクタによってではなく、決定論的にです。

## 参照がカウントに与える影響

- **strong**（デフォルト）— カウントを増やし、オブジェクトを生かし続けます。
- **weak** — カウントを増やさず、解放時に自動的に `nil` に設定されます。`var` かつOptionalでなければなりません。
- **unowned** — カウントを増やさず、常に有効であると仮定されます。解放後にアクセスするとクラッシュします（あるいは `unowned(unsafe)` ではさらに悪い未定義動作になります）。

```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 — その判断

習慣ではなく**生存期間の関係**で選んでください:

| | weak | unowned |
|--|------|---------|
| Optional | はい（nilになる） | いいえ |
| ARCコスト | やや高い（追跡される） | 低い |
| 相手のオブジェクトが消えても安全か | はい | **クラッシュ** |
| 使う場面 | 参照が*正当に* nilになり得る場合（delegate、先に解放され得る親） | 参照がself より確実に長生きする場合（子 → 必須の親） |

## リークの検出

1. **Xcode Memory Graph Debugger** — 一時停止して、消えているはずのオブジェクトを探します。紫色の `!` マーカーが循環を示します。
2. **Instruments → Leaks / Allocations** — フローを繰り返すたびにメモリが単調に増加しないか観察します。
3. **`deinit` ロギング** — 最速のサニティチェックです。画面を閉じたときに `deinit` が決してプリントされなければ、そのオブジェクトはリークしています。

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

## よくあるリークの原因

`self` をキャプチャするエスケープクロージャ、双方向の親子間の強参照、ターゲットを保持する `Timer`/`DispatchSourceTimer`、そして解放されるcancellableに格納されていないCombineの購読などです。

## なぜ重要なのか

ARCは決定論的なので、リークはGCではなくあなたの責任です。保持されたビューコントローラー1つが、数メガバイトの画像とそのオブジェクトグラフ全体をピン留めしかねません。シニア面接がこれを探るのは、weak と unowned を正しく選び、メモリグラフでリークを*証明する*方法を知っていることが、長時間動作するアプリの肥大化を防ぐからです。

	weak	unowned
Optional	はい（nilになる）	いいえ
ARCコスト	やや高い（追跡される）	低い
相手のオブジェクトが消えても安全か	はい	クラッシュ
使う場面	参照が正当に nilになり得る場合（delegate、先に解放され得る親）	参照がself より確実に長生きする場合（子 → 必須の親）

参照がカウントに与える影響

weak と unowned — その判断

リークの検出

よくあるリークの原因

なぜ重要なのか

関連する質問