อธิบาย ARC เชิงลึก: weak เทียบกับ unowned และวิธีตรวจจับ memory leak

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** จัดการหน่วยความจำสำหรับ instance ของ class ด้วยการติดตาม strong reference ตั้งแต่ตอน compile: compiler จะแทรกการเรียก `retain`/`release` และเมื่อ strong count ของ object เป็นศูนย์ มันจะถูก deallocate ทันที — อย่างแน่นอน (deterministic) ไม่ใช่ด้วย garbage collector ที่ทำงานเบื้องหลัง

## reference ส่งผลต่อ count อย่างไร

- **strong** (ค่าเริ่มต้น) — เพิ่ม count; ทำให้ object มีชีวิตอยู่
- **weak** — *ไม่* เพิ่ม count; ถูกตั้งเป็น `nil` โดยอัตโนมัติเมื่อถูก deallocate ต้องเป็น `var` และเป็น optional
- **unowned** — *ไม่* เพิ่ม count; ถือว่าใช้งานได้เสมอ การเข้าถึงหลังจาก deallocate แล้วคือ crash (หรือแย่กว่านั้นคือ undefined behavior กับ `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 — การตัดสินใจ

เลือกตาม **ความสัมพันธ์ด้าน lifetime** ไม่ใช่ตามความเคยชิน:

| | weak | unowned |
|--|------|---------|
| Optional | ใช่ (กลายเป็น nil) | ไม่ |
| ต้นทุน ARC | สูงกว่าเล็กน้อย (ถูกติดตาม) | ต่ำกว่า |
| ปลอดภัยถ้า object อีกตัวหายไป | ใช่ | **crash** |
| ใช้เมื่อ | reference *สามารถ* กลายเป็น nil ได้อย่างสมเหตุสมผล (delegate, parent ที่อาจถูก deallocate ก่อน) | reference ถูกรับประกันว่าจะมีอายุยืนกว่า self (ลูก → parent ที่ต้องมีเสมอ) |

## การตรวจจับ leak

1. **Xcode Memory Graph Debugger** — หยุดชั่วคราวแล้วมองหา object ที่ควรหายไปแล้ว; เครื่องหมาย `!` สีม่วงจะระบุ cycle
2. **Instruments → Leaks / Allocations** — เฝ้าดูหน่วยความจำที่โตขึ้นเรื่อย ๆ ขณะที่คุณทำ flow เดิมซ้ำ ๆ
3. **การ log ใน `deinit`** — การตรวจสอบเร็วที่สุด: ถ้า `deinit` ไม่เคย print ตอนปิดหน้าจอ แสดงว่า object นั้นรั่ว

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

## แหล่งที่มาของ leak ที่พบบ่อย

closure ที่ escape และ capture `self`, strong reference สองทางระหว่าง parent/child, `Timer`/`DispatchSourceTimer` ที่ยึด target ไว้, และ Combine subscription ที่ไม่ได้เก็บไว้ใน cancellable ที่จะถูก deallocate

## ทำไมจึงสำคัญ

ARC เป็นแบบแน่นอน (deterministic) ดังนั้น leak จึงเป็นความรับผิดชอบของคุณ ไม่ใช่ของ GC — view controller ที่ถูกยึดไว้เพียงตัวเดียวสามารถตรึงรูปภาพหลายเมกะไบต์และ object graph ทั้งก้อนของมันไว้ได้ การสัมภาษณ์ระดับ senior เจาะเรื่องนี้เพราะการเลือก weak เทียบกับ unowned ได้ถูกต้อง และรู้วิธี *พิสูจน์* leak ด้วย memory graph คือสิ่งที่ทำให้แอปที่ทำงานยาวนานไม่บวมขึ้นเรื่อย ๆ

	weak	unowned
Optional	ใช่ (กลายเป็น nil)	ไม่
ต้นทุน ARC	สูงกว่าเล็กน้อย (ถูกติดตาม)	ต่ำกว่า
ปลอดภัยถ้า object อีกตัวหายไป	ใช่	crash
ใช้เมื่อ	reference สามารถ กลายเป็น nil ได้อย่างสมเหตุสมผล (delegate, parent ที่อาจถูก deallocate ก่อน)	reference ถูกรับประกันว่าจะมีอายุยืนกว่า self (ลูก → parent ที่ต้องมีเสมอ)

reference ส่งผลต่อ count อย่างไร

weak เทียบกับ unowned — การตัดสินใจ

การตรวจจับ leak

แหล่งที่มาของ leak ที่พบบ่อย

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง