09 · 메모리 릭 원인 및 대응

// ❌ self가 클로저를 저장하고, 클로저가 self를 강하게 잡는다
final class ViewModel {
    var onUpdate: (() -> Void)?
    func bind() {
        onUpdate = { self.reload() }         // self ↔ onUpdate 순환
    }
    func reload() { }
    deinit { print("deinit") }               // 절대 안 불린다
}

// ✅ 캡처 리스트로 끊는다
onUpdate = { [weak self] in
    guard let self else { return }
    self.reload()
}

// ✅ 필요한 것만 캡처하는 것도 방법 — self를 아예 안 잡는다
let logger = self.logger
onUpdate = { logger.log("updated") }         // self가 캡처되지 않는다

// ❌ strong delegate
protocol LoaderDelegate { func didFinish() }
final class Loader {
    var delegate: LoaderDelegate?            // strong! 부모를 잡는다
}

// ✅ AnyObject 제약 + weak
protocol LoaderDelegate: AnyObject { func didFinish() }
final class Loader {
    weak var delegate: LoaderDelegate?       // weak은 클래스 타입에만 가능
}
// AnyObject 제약이 필요한 이유: 값 타입은 참조 카운팅 대상이 아니라
// weak을 걸 수 없다. 그래서 컴파일러가 클래스 전용임을 요구한다.

// ❌ target-action 형은 Timer가 target을 강하게 잡는다
timer = Timer.scheduledTimer(timeInterval: 1, target: self,
                             selector: #selector(tick),
                             userInfo: nil, repeats: true)
// RunLoop → Timer → self  (self가 timer를 들고 있으면 순환까지 완성)

// ✅ 블록 API + weak self
timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [weak self] _ in
    self?.tick()
}

// ⚠️ 하지만 weak self 만으로는 부족하다!
//    RunLoop가 Timer를 계속 잡고 있으므로 타이머는 영원히 발화한다.
//    self가 죽어도 self?.tick() 이 무시될 뿐, 타이머는 계속 돈다.
override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    timer?.invalidate()          // ✅ 반드시 명시적으로 무효화
    timer = nil
}
// 같은 구조: CADisplayLink, DispatchSourceTimer

// ❌ 세션이 delegate를 강하게 잡는다 — 앱 종료까지 유지된다
final class Downloader: NSObject, URLSessionDelegate {
    private lazy var session = URLSession(configuration: .default,
                                          delegate: self,      // strong!
                                          delegateQueue: nil)
    deinit { print("deinit") }   // 안 불린다
}

// ✅ 명시적으로 무효화해야 delegate를 놓는다
final class Downloader: NSObject, URLSessionDelegate {
    private lazy var session = URLSession(configuration: .default,
                                          delegate: self, delegateQueue: nil)
    func finish() {
        session.finishTasksAndInvalidate()   // 진행 중 작업은 끝내고 해제
        // 또는 session.invalidateAndCancel()  // 즉시 취소하고 해제
    }
}

// ✅ 애초에 delegate가 필요 없으면 shared 나 async API를 쓴다
let (data, _) = try await URLSession.shared.data(from: url)   // 릭 걱정 없음

// ✅ 셀렉터형: iOS 9+ 부터 옵저버가 죽으면 자동 해제된다
NotificationCenter.default.addObserver(
    self, selector: #selector(handle), name: .foo, object: nil)

// ⚠️ 블록형: 반환 토큰을 보관했다가 직접 제거해야 한다
private var token: NSObjectProtocol?
token = NotificationCenter.default.addObserver(
    forName: .foo, object: nil, queue: .main
) { [weak self] _ in                      // ← self 캡처도 주의
    self?.handle()
}
deinit {
    if let token { NotificationCenter.default.removeObserver(token) }
}

// ✅ 더 나은 대안 — 수명이 구조적으로 관리된다
for await _ in NotificationCenter.default.notifications(named: .foo) {
    handle()
}   // Task가 취소되면 자동으로 정리된다

// 질문: "이 클로저를 self(또는 self가 소유한 것)가 저장하는가?"
//        저장하면 weak,  아니면 불필요.

// ───── ① non-escaping — 순환이 원리적으로 불가능 ─────
let doubled = numbers.map { self.transform($0) }     // ✅ weak 불필요
items.forEach { self.process($0) }                   // ✅ weak 불필요
// 함수가 반환되기 전에 끝나므로 self를 붙잡은 채 남을 수 없다

// ───── ② 한 번 실행되고 해제되는 escaping — 순환이 아니다 ─────
DispatchQueue.main.async {
    self.updateUI()                                  // ✅ weak 불필요
}   // 실행 후 클로저가 해제되며 self도 놓는다. 잠깐 수명이 연장될 뿐이다

UIView.animate(withDuration: 0.3) {
    self.view.alpha = 0                              // ✅ weak 불필요
}

// ───── ③ self가 저장하는 escaping — 여기가 진짜 위험 ─────
final class VM {
    var handler: (() -> Void)?
    func bind() {
        handler = { self.reload() }                  // ❌ weak 필요!
    }
}

// ───── ④ weak을 쓰면 오히려 버그가 되는 경우 ─────
func saveAndClose() {
    api.upload(data) { [weak self] result in         // ⚠️ 위험한 선택
        self?.markSaved()                            // 화면이 닫히면 저장 기록이 안 남는다
    }
}
// ✅ 끝까지 실행돼야 하는 작업은 self를 잡거나, self와 무관한 객체가 담당한다
func saveAndClose() {
    let store = self.store                           // self 대신 필요한 것만
    api.upload(data) { result in store.markSaved(result) }
}

// weak    : 대상이 죽으면 자동으로 nil. Optional. 안전. side table 비용 약간
// unowned : Optional 아님, 더 빠름. 대상이 먼저 죽으면 💥 크래시

// ✅ unowned가 안전한 전형 — 자식이 부모보다 오래 살 수 없는 구조
final class Customer {
    var card: CreditCard?
    deinit { print("Customer 해제") }
}
final class CreditCard {
    unowned let owner: Customer      // 카드는 소유자 없이 존재할 수 없다
    init(owner: Customer) { self.owner = owner }
}

// ❌ unowned가 위험한 전형 — 비동기 콜백
api.load { [unowned self] data in    // 응답 오기 전에 화면을 닫으면 💥
    self.items = data
}

// 규칙: 비동기·콜백·수명이 불확실 → weak
//       구조적으로 부모가 더 오래 삼이 보장 → unowned (그리고 주석으로 근거)

final class Node {
    let id: Int
    init(id: Int) { self.id = id }
    deinit { print("deinit \(id)") }
}

var strongRef: Node? = Node(id: 1)
weak var weakRef = strongRef

strongRef = nil          // "deinit 1" 출력 — deinit은 여기서 실행된다
print(weakRef == nil)    // true — weak 접근은 nil

// 하지만 weakRef 변수가 스코프에 살아 있는 동안
// side table은 아직 남아 있다 (weak count > 0).
// → deinit 실행 시점 ≠ 메모리 완전 반환 시점

// unowned 는 이 검사를 생략하기 때문에 더 빠르지만,
// 죽은 객체에 접근하면 검사 없이 진행 → 크래시(또는 그보다 나쁜 것)

// ── ① deinit 로그: 가장 싸고 가장 확실한 1차 판별 ──
deinit { print("✅ \(type(of: self)) deinit") }

// 화면을 닫았는데 안 찍히면 → 붙잡혀 있다
// ⚠️ 단, "안 찍힘 = 릭"은 아니다. 네비게이션 스택이나 캐시에
//    정당하게 남아 있을 수도 있다. 다음 단계로 확인한다.

// ── ② Memory Graph Debugger: 누가 붙잡고 있는지 그림으로 ──
//    Xcode 디버그 중 [Debug Memory Graph] 버튼
//    · 왼쪽 트리에서 해당 클래스 검색
//    · 인스턴스를 고르면 오른쪽에 "들어오는 참조" 화살표가 전부 보인다
//    · 보라색 ! 배지 = 런타임이 릭으로 판정한 것
//    순환 참조를 찾는 데는 이게 가장 강력하다.

// ── ③ Instruments → Leaks: 도달 불가 메모리 ──
//    ⚠️ 순환 참조는 "서로 도달 가능"이라 Leaks가 못 잡는 경우가 있다

// ── ④ Instruments → Allocations + Mark Generation ──
//    화면 진입 → Mark Generation → 화면 이탈 → Mark Generation
//    이걸 3~5회 반복했을 때 세대별 잔존 바이트가 계속 늘면 문제.
//    ★ abandoned memory는 여기서만 잡힌다.

// ── ⑤ 회귀 방지: 릭 확인을 테스트로 ──
func testNoLeak() {
    weak var weakVC: FeedViewController?
    autoreleasepool {
        let vc = FeedViewController()
        vc.loadViewIfNeeded()
        weakVC = vc
    }
    XCTAssertNil(weakVC, "FeedViewController가 해제되지 않았습니다")
}

Swift / ObjC  : 순환을 개발자가 끊는다 (weak / unowned)
                → 사이클 수집기를 "넣지 않기로 선택"했다. 성능·결정성을 산 것.

Python        : 참조 카운팅 + 사이클 수집기 병행  ← "RC는 사이클을 못 잡는다"의 반례
                → gc 모듈이 trial deletion으로 순환을 수집한다 (비결정적 요소 도입)

C++ shared_ptr: weak_ptr 로 개발자가 끊는다 (Swift와 같은 철학)

Rust          : Rc/RefCell 순환 가능 → Weak 으로 끊는다
                단, 소유권 모델 덕에 애초에 Rc를 쓸 일이 적다

Java / C#     : 추적 GC — 사이클을 자동으로 수집
                대신 정지 시간과 메모리 여유가 필요하다

// ── ① 진짜 릭 (leaked) — 도달 불가인데 해제 안 됨 ──
//     원인: 순환 참조, C 메모리 free 누락
//     도구: Leaks, Memory Graph Debugger

// ── ② abandoned memory — 도달 가능한데 아무도 안 씀 ──
//     ⚠️ Leaks 도구에 안 잡힌다. 참조가 살아 있으니까.
final class ImageCache {
    static let shared = ImageCache()
    private var cache: [URL: UIImage] = [:]      // 무제한 증가
    func store(_ img: UIImage, for url: URL) { cache[url] = img }
}
// ✅ NSCache는 메모리 압박 시 자동 방출된다
final class BetterCache {
    private let cache = NSCache<NSURL, UIImage>()
    init() {
        cache.countLimit = 100
        cache.totalCostLimit = 50 * 1024 * 1024   // 50MB
    }
}

// ── ③ 정상적인 큰 사용량 — 릭도 abandoned도 아님 ──
//     원본 이미지를 그대로 들고 있는 경우 등
//     4000×3000 이미지 하나 = 4000*3000*4 ≈ 48MB (디코딩된 비트맵)
// ✅ 다운샘플링으로 필요한 크기만 (11번 참조)

// 데스크톱 (Linux/macOS)
//   물리 메모리 부족 → 페이지를 디스크로 스왑 → 느려지지만 계속 동작
//   그래도 부족하면 → OOM Killer가 프로세스 종료 (최후 수단)

// iOS — Jetsam (XNU의 memorystatus 서브시스템)
//   ⚠️ 앱 메모리에 대한 스왑이 없다 (플래시 수명·전력 때문)
//   → dirty 페이지를 회수할 방법이 없으니 "종료"가 1차 수단이 된다
//   → "느려지는 단계" 없이 바로 죽는다
//
//   그리고 축이 두 개다 — 이걸 구분해서 말하면 확실히 다르다:
//
//   ① 우선순위 밴드 (전역 메모리 부족 시)
//        Foreground 앱      ← 가장 마지막에 종료 (사용자가 보는 중)
//        Suspended 백그라운드
//        백그라운드 데몬 · 유휴   ← 여기부터 죽는다
//
//   ② 앱별 메모리 상한 (per-process limit)  ★ 실무에서 더 자주 겪는 쪽
//        전역 메모리가 넉넉해도, 내 앱이 상한을 넘으면 내 앱만 콕 집어 종료된다.
//        즉 "기기 메모리가 남았는데 왜 죽지?"의 답이 이것이다.
//
//   → 리눅스 OOM killer는 반응적·전역적(사후에 oom_score로 희생자 선정)이고,
//     Jetsam은 선제적·협조적·우선순위 기반이다. 성격이 다르다.

// 앱이 받는 신호 — 두 계층이 있다
// ① UIKit 수준 (거칠다)
override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()
    imageCache.removeAllObjects()          // 다시 만들 수 있는 것부터 버린다
}

// ② DispatchSource 수준 (normal / warning / critical 로 세밀하다)
let src = DispatchSource.makeMemoryPressureSource(
    eventMask: [.warning, .critical], queue: .main)
src.setEventHandler {
    switch src.data {
    case .warning:  imageCache.countLimit = 20   // 줄이기
    case .critical: imageCache.removeAllObjects() // 전부 비우기
    default: break
    }
}
src.resume()
// 여기서 footprint를 줄이면 Jetsam을 피할 수 있다 — 경고는 "기회"다
// SwiftUI / 일반
NotificationCenter.default.addObserver(
    forName: UIApplication.didReceiveMemoryWarningNotification,
    object: nil, queue: .main) { _ in purgeCaches() }

// 우선순위: 포그라운드 앱이 가장 안전, 백그라운드 앱이 먼저 죽는다
// → 그래서 "백그라운드 갔다 오면 앱이 재시작되는" 현상이 생긴다
// → 상태 복원(state restoration)이 필요한 이유

// 크래시 리포트에서 구분하는 법
//   EXC_RESOURCE / JETSAM  → 메모리 초과로 종료됨 (일반 크래시가 아니다)