深入解释 ARC：weak vs unowned，以及如何检测泄漏。

Question

IT Interview Practice · Accepted Answer

**ARC（自动引用计数）**通过在编译期跟踪强引用来管理类实例的内存：编译器会插入 `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 vs 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` 持有其 target，以及未存储在会被释放的 cancellable 中的 Combine 订阅。

## 为什么这很重要

ARC 是确定性的，所以泄漏是你的责任，而不是 GC 的——一个被保留的 view controller 就能钉住数兆字节的图片以及它整个对象图。资深面试会探究这一点，因为正确地在 weak 与 unowned 之间选择、并知道如何用内存图*证明*泄漏，正是让长时间运行的 app 不至于内存膨胀的关键。

	weak	unowned
Optional	是（会变为 nil）	否
ARC 成本	略高（需跟踪）	较低
另一对象消失时是否安全	安全	崩溃
使用场景	该引用可以合理地变为 nil（delegate、可能先释放的父对象）	该引用保证比 self 活得更久（子对象 → 必存在的父对象）

引用如何影响计数

weak vs unowned——如何抉择

检测泄漏

常见泄漏来源

为什么这很重要

相关问题