Python จัดการหน่วยความจำและ garbage collection อย่างไร?

Question

Accepted Answer

Python จัดการหน่วยความจำ**โดยอัตโนมัติ**โดยใช้สองกลไก: **reference counting** (วิธีหลัก) บวกกับ **cyclic garbage collector** ที่จัดการกับ reference cycle คุณไม่เคยต้องคืนหน่วยความจำเอง แต่การเข้าใจว่ามันทำงานอย่างไรช่วยอธิบายพฤติกรรมของหน่วยความจำและการรั่วไหล (leak)

## Reference counting — กลไกหลัก

```python
import sys

x = [1, 2, 3]        # the list object has refcount 1
y = x                 # refcount 2 (another name references it)
sys.getrefcount(x)    # shows the count (slightly higher due to the call itself)

del y                 # refcount 1
del x                 # refcount 0 → the object is FREED immediately
```

ทุก object จะติดตามว่ามี reference ชี้มาหามันกี่ตัว เมื่อจำนวนลดลงเหลือ **ศูนย์** หน่วยความจำจะถูกคืน**ทันที** สิ่งนี้เป็นแบบกำหนดได้แน่นอน (deterministic) และฉับไว — object จะถูกทำลายทันทีที่ไม่มีอะไรอ้างถึงมันอีก

## ปัญหา: reference cycle

```python
# reference counting alone can't free this:
a = {}
b = {}
a["b"] = b      # a references b
b["a"] = a      # b references a → they reference EACH OTHER
del a, b        # the names are gone, but the objects still reference each other
# → refcounts never reach 0 → they'd leak with refcounting alone
```

สอง object ที่อ้างถึงกันและกันจะทำให้ refcount ของอีกฝ่ายสูงกว่าศูนย์ แม้ว่าจะเข้าถึงไม่ได้แล้ว — เป็น cycle ที่ reference counting ล้วน ๆ ไม่สามารถเก็บกวาดได้

## cyclic garbage collector

```python
import gc

# the generational GC periodically finds and frees unreachable CYCLES
gc.collect()        # manually trigger a collection
gc.get_count()      # objects tracked per generation
```

**generational garbage collector** เสริมของ Python จะตรวจจับและคืน cycle ที่เข้าถึงไม่ได้เหล่านี้เป็นระยะ ๆ มันเป็นแบบ *generational* — object ที่ใหม่กว่าจะถูกตรวจบ่อยกว่า (object ส่วนใหญ่ตายตั้งแต่ยังอายุน้อย) ซึ่งมีประสิทธิภาพ

## ผลกระทบเชิงปฏิบัติและแหล่งที่มาของการรั่วไหล

```text
✓ Most memory is reclaimed promptly via reference counting
⚠️ Leaks still happen from REACHABLE references that outlive their usefulness:
   - global caches/lists that only grow
   - objects held by long-lived closures or class attributes
   - registered callbacks/listeners never removed
```

GC จัดการกับ cycle ได้ แต่มันไม่สามารถคืน object ที่ยัง *เข้าถึงได้* การ "รั่วไหล" ที่พบได้บ่อยในโลกจริงคือการเก็บ reference ไว้โดยไม่ตั้งใจ (เช่น global cache ที่โตขึ้นเรื่อย ๆ)

## รายละเอียดอื่น ๆ

```text
- Small integers (-5..256) and short strings are CACHED/interned (shared, reused)
- CPython uses memory pools (pymalloc) for small objects (efficiency)
```

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

การเข้าใจโมเดลหน่วยความจำของ Python — reference counting ที่ฉับไว บวกกับ cyclic GC — ช่วยอธิบายพฤติกรรมจริง: ทำไม object มักถูกคืนทันที ทำไม reference cycle ต้องอาศัย GC และที่สำคัญคือทำไม "memory leak" ใน Python จึงมาจาก reference ที่ *เข้าถึงได้* (cache ที่โตขึ้น closure ที่ค้างอยู่ callback ที่ไม่ได้ลบออก) มากกว่าการลืมคืนหน่วยความจำ

ความรู้นี้จำเป็นสำหรับการวินิจฉัยการเติบโตของหน่วยความจำในบริการที่ทำงานยาวนาน และสำหรับการเขียนโค้ดที่คำนึงถึงหน่วยความจำ — โดยรู้ว่าวิธีแก้มักจะคือการตัด reference (จำกัดขนาด cache ทำความสะอาดการลงทะเบียน) มากกว่าสิ่งใด ๆ ที่ GC จะทำให้คุณได้