Python은 메모리와 가비지 컬렉션을 어떻게 관리하나요?

Question

Accepted Answer

Python은 두 가지 메커니즘을 사용하여 메모리를 **자동으로** 관리합니다: **참조 카운팅(reference counting)**(주된 방법)과 참조 순환을 처리하는 **순환 가비지 컬렉터(cyclic garbage collector)**입니다. 메모리를 수동으로 해제하지는 않지만, 작동 방식을 이해하면 메모리 동작과 누수를 설명할 수 있습니다.

## 참조 카운팅 — 주된 메커니즘

```python
import sys

x = [1, 2, 3]        # 리스트 객체의 참조 카운트는 1
y = x                 # 참조 카운트 2 (또 다른 이름이 참조)
sys.getrefcount(x)    # 카운트를 보여줌 (호출 자체 때문에 약간 더 높음)

del y                 # 참조 카운트 1
del x                 # 참조 카운트 0 → 객체가 즉시 해제됨
```

모든 객체는 자신을 가리키는 참조의 수를 추적합니다. 카운트가 **0**으로 떨어지면 메모리가 **즉시** 해제됩니다. 이는 결정적이고 신속합니다 — 아무것도 참조하지 않는 즉시 객체가 소멸됩니다.

## 문제: 참조 순환

```python
# 참조 카운팅만으로는 이것을 해제할 수 없음:
a = {}
b = {}
a["b"] = b      # a가 b를 참조
b["a"] = a      # b가 a를 참조 → 서로를 참조함
del a, b        # 이름은 사라졌지만 객체들은 여전히 서로를 참조함
# → 참조 카운트가 절대 0에 도달하지 않음 → 참조 카운팅만으로는 누수됨
```

서로를 참조하는 두 객체는 도달 불가능하더라도 서로의 참조 카운트를 0 이상으로 유지합니다 — 순수 참조 카운팅으로는 수집할 수 없는 순환입니다.

## 순환 가비지 컬렉터

```python
import gc

# 세대별 GC가 주기적으로 도달 불가능한 순환을 찾아 해제함
gc.collect()        # 수집을 수동으로 트리거
gc.get_count()      # 세대별로 추적되는 객체
```

Python의 보조적인 **세대별 가비지 컬렉터**는 이러한 도달 불가능한 순환을 주기적으로 감지하고 해제합니다. *세대별*입니다 — 더 새로운 객체가 더 자주 검사됩니다(대부분의 객체는 일찍 소멸함). 이는 효율적입니다.

## 실질적 함의 및 누수 원인

```text
✓ 대부분의 메모리는 참조 카운팅을 통해 신속하게 회수됨
⚠️ 유용성을 넘어 살아남는 도달 가능한 참조로부터 여전히 누수가 발생함:
   - 계속 커지기만 하는 전역 캐시/리스트
   - 오래 사는 클로저나 클래스 속성이 보유한 객체
   - 제거되지 않은 등록된 콜백/리스너
```

GC는 순환을 처리하지만, 여전히 *도달 가능한* 객체는 해제할 수 없습니다 — 흔한 실제 "누수"는 의도치 않게 참조를 살려두는 것입니다(예: 계속 커지는 전역 캐시).

## 기타 세부 사항

```text
- 작은 정수(-5..256)와 짧은 문자열은 캐시/인터닝됨 (공유, 재사용)
- CPython은 작은 객체에 메모리 풀(pymalloc)을 사용함 (효율성)
```

## 왜 중요한가

Python의 메모리 모델 — 신속한 참조 카운팅과 순환 GC — 을 이해하면 실제 동작을 설명할 수 있습니다: 객체가 보통 즉시 해제되는 이유, 참조 순환이 GC를 필요로 하는 이유, 그리고 결정적으로 Python에서 "메모리 누수"가 잊혀진 해제가 아니라 *도달 가능한* 참조(커지는 캐시, 남아 있는 클로저, 제거되지 않은 콜백)에서 오는 이유 등입니다.

이 지식은 오래 실행되는 서비스에서 메모리 증가를 진단하고 메모리를 의식하는 코드를 작성하는 데 필수적입니다 — 해결책은 보통 GC가 해줄 수 있는 무언가가 아니라 참조를 끊는 것(캐시 제한, 등록 정리)임을 아는 것이죠.