Giải thích ARC chuyên sâu: weak vs unowned, và cách phát hiện leak.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** quản lý bộ nhớ cho instance của class bằng cách theo dõi strong reference lúc biên dịch: compiler chèn các lời gọi `retain`/`release`, và khi strong count của object về 0 nó được giải phóng ngay lập tức — một cách xác định (deterministic), không qua garbage collector chạy nền.

## Tham chiếu ảnh hưởng tới count ra sao

- **strong** (mặc định) — tăng count; giữ object sống.
- **weak** — *không* tăng; tự động về `nil` khi object bị giải phóng. Phải là `var` và optional.
- **unowned** — *không* tăng; được giả định luôn hợp lệ. Truy cập sau khi đã deallocate sẽ crash (hoặc tệ hơn, hành vi không xác định với `unowned(unsafe)`).

```swift
final class Customer {
    var card: Card?                 // strong: customer sở hữu card
}
final class Card {
    unowned let owner: Customer     // unowned: card không bao giờ sống lâu hơn owner
    init(owner: Customer) { self.owner = owner }
}
```

## weak vs unowned — cách quyết định

Chọn theo **quan hệ vòng đời**, không theo thói quen:

| | weak | unowned |
|--|------|---------|
| Optional | có (thành nil) | không |
| Chi phí ARC | cao hơn chút (có theo dõi) | thấp hơn |
| An toàn nếu object kia đã mất | có | **crash** |
| Dùng khi | tham chiếu *có thể* thành nil hợp lệ (delegate, cha có thể giải phóng trước) | tham chiếu chắc chắn sống lâu hơn self (con → cha bắt buộc) |

## Phát hiện leak

1. **Xcode Memory Graph Debugger** — tạm dừng và tìm object lẽ ra đã mất; dấu `!` tím báo hiệu cycle.
2. **Instruments → Leaks / Allocations** — theo dõi bộ nhớ tăng đều khi bạn lặp lại một luồng.
3. **Log trong `deinit`** — cách kiểm tra nhanh nhất: nếu `deinit` không bao giờ in khi màn hình đóng, object đó đã leak.

```swift
deinit { print("released \(Self.self)") }  // im lặng khi dismiss = leak
```

## Nguồn leak thường gặp

Escaping closure capture `self`, hai tham chiếu strong cha/con hai chiều, `Timer`/`DispatchSourceTimer` giữ target của chúng, và Combine subscription không được lưu trong một cancellable sẽ giải phóng.

## Tại sao điều này quan trọng

ARC mang tính xác định, nên leak là trách nhiệm của bạn, không phải của GC — chỉ một view controller bị giữ lại có thể ghim hàng megabyte ảnh cùng toàn bộ đồ thị object của nó. Phỏng vấn senior dò điều này vì chọn đúng weak vs unowned và biết cách *chứng minh* một leak bằng memory graph là thứ giữ cho app chạy lâu không phình bộ nhớ.

	weak	unowned
Optional	có (thành nil)	không
Chi phí ARC	cao hơn chút (có theo dõi)	thấp hơn
An toàn nếu object kia đã mất	có	crash
Dùng khi	tham chiếu có thể thành nil hợp lệ (delegate, cha có thể giải phóng trước)	tham chiếu chắc chắn sống lâu hơn self (con → cha bắt buộc)

Tham chiếu ảnh hưởng tới count ra sao

weak vs unowned — cách quyết định

Phát hiện leak

Nguồn leak thường gặp

Tại sao điều này quan trọng

Câu hỏi liên quan