02 · 동시성·병렬성·스레드

import Foundation

// ❌ 여러 스레드가 동기화 없이 만지는 공유 상태 — data race(UB)
final class UnsafeCounter {
    private var value = 0
    func increment() { value += 1 }     // 읽기·더하기·쓰기 사이에 끼어들 수 있다
    var current: Int { value }
}

// ✅ ① actor — 컴파일러가 격리를 강제한다(가장 권장)
actor Counter {
    private var value = 0
    func increment() { value += 1 }
    func current() -> Int { value }
}

// ✅ ② 락 — 동기 API를 유지해야 할 때
import os
final class LockedCounter: @unchecked Sendable {
    // 모든 접근이 이 락을 통과한다 — 아래 두 메서드가 유일한 진입점이다
    private let state = OSAllocatedUnfairLock(initialState: 0)
    func increment() { state.withLock { $0 += 1 } }
    func current() -> Int { state.withLock { $0 } }
}

// ✅ ③ serial queue — 레거시 코드와 섞여 있을 때
final class QueuedCounter {
    private var value = 0
    private let queue = DispatchQueue(label: "com.app.counter")
    func increment() { queue.async { self.value += 1 } }
    func current() -> Int { queue.sync { value } }
}

// 셋 다 목적은 같다: "한 번에 하나만 이 상태를 만진다"

import Foundation

// 스레드는 주소 공간을 공유한다 — 한 스레드가 메모리를 깨뜨리면 프로세스 전체가 죽는다.
// 진짜 격리가 필요하면 경계는 스레드가 아니라 '프로세스'여야 한다.

// ✅ 신뢰할 수 없는 입력을 다루는 무거운 작업을 App Extension으로 분리
//    (예: 사용자가 올린 파일 파싱·썸네일 생성)
//    확장이 죽어도 호스트 앱은 살아 있다.

// 호스트 앱 쪽 — 확장에 작업을 넘기고 결과만 받는다
import UniformTypeIdentifiers

func requestThumbnail(for url: URL) async throws -> Data {
    // App Group 컨테이너에 입력을 두고 확장이 읽게 한다
    let shared = FileManager.default.containerURL(
        forSecurityApplicationGroupIdentifier: "group.com.app")!
    let input = shared.appendingPathComponent("in.bin")
    try Data(contentsOf: url).write(to: input, options: .atomic)

    // 확장 호출(예: Share/Action Extension, 또는 XPC 기반 서비스)
    return try await ThumbnailService.shared.run(inputAt: input)
}

enum ThumbnailService {
    static let shared = ThumbnailServiceImpl()
}
struct ThumbnailServiceImpl {
    func run(inputAt url: URL) async throws -> Data { Data() }
}

// ⚠️ 대가: IPC 직렬화 비용 + 확장의 메모리 상한이 본체보다 훨씬 낮다.
//    "크래시 격리 가치 > IPC 비용"일 때만 고른다.
// ⚠️ iOS에는 macOS 같은 임의 XPC 서비스가 없다 — 확장 종류가 정해져 있다.

import Foundation

// 스레드 로컬 저장소(TLS)는 '이 스레드가 내 것'이라는 가정 위에서만 맞다.
// GCD·Swift Concurrency는 스레드를 풀에서 빌려 쓰므로 그 가정이 깨진다.

// ❌ 스레드가 재사용되면 이전 작업의 값이 그대로 남아 있다
func handleBad(requestID: String) {
    Thread.current.threadDictionary["requestID"] = requestID
    process()
}
func process() {
    let id = Thread.current.threadDictionary["requestID"] as? String
    print("처리 중: \(id ?? "없음")")     // 엉뚱한 요청 ID가 찍힐 수 있다
}

// ✅ ① 그냥 인자로 넘긴다 — 가장 단순하고 확실하다
func handle(requestID: String) { process(requestID: requestID) }
func process(requestID: String) { print("처리 중: \(requestID)") }

// ✅ ② 호출 깊이가 깊어 인자 전달이 번거로우면 task-local 값을 쓴다
//     (Task 단위로 스코프가 잡히므로 스레드 재사용과 무관하다)
enum RequestContext {
    @TaskLocal static var id: String = "-"
}

func handleAsync(requestID: String) async {
    await RequestContext.$id.withValue(requestID) {
        await deepWork()
    }
}

func deepWork() async {
    print("처리 중: \(RequestContext.id)")   // ✅ 항상 이 Task의 값
}

import Foundation

// I/O는 CPU가 노는 시간이 대부분이다. 스레드를 늘려 봐야
// 노는 스레드가 늘 뿐, 대기 시간 자체는 줄지 않는다.

// ❌ 스레드를 늘려 해결하려는 시도 — thread explosion만 부른다
func fetchAllBad(_ urls: [URL]) {
    for url in urls {
        DispatchQueue.global().async {
            _ = try? Data(contentsOf: url)     // 스레드를 붙잡고 대기
        }
    }
}

// ✅ 대기를 '겹친다' — 스레드는 그대로 두고 왕복만 병행시킨다
func fetchAll(_ urls: [URL]) async throws -> [Data] {
    try await withThrowingTaskGroup(of: (Int, Data).self) { group in
        for (i, url) in urls.enumerated() {
            group.addTask {
                let (data, _) = try await URLSession.shared.data(from: url)
                return (i, data)
            }
        }
        // 순서를 보존해 모은다
        var out = [Data?](repeating: nil, count: urls.count)
        for try await (i, data) in group { out[i] = data }
        return out.compactMap { $0 }
    }
}

// 소수의 고정 개수라면 async let이 더 읽기 쉽다
func loadScreen() async throws -> (Profile, [Post]) {
    async let profile = api.profile()
    async let posts = api.posts()
    return try await (profile, posts)          // 두 왕복이 겹쳐서 진행된다
}

struct Profile {}; struct Post {}
enum api {
    static func profile() async throws -> Profile { Profile() }
    static func posts() async throws -> [Post] { [] }
}

import Foundation

// 코어보다 많은 병렬 스레드는 이득이 없고 스위칭·캐시 미스로 손해다.

let cores = ProcessInfo.processInfo.activeProcessorCount

// ✅ ① concurrentPerform — 런타임이 코어 수에 맞춰 분배한다
func renderTiles(_ tiles: [Tile], into out: UnsafeMutableBufferPointer<Pixel>) {
    DispatchQueue.concurrentPerform(iterations: tiles.count) { i in
        out[i] = render(tiles[i])
    }
}

// ✅ ② TaskGroup을 쓰되 '작업 개수'가 아니라 '청크 개수'를 코어에 맞춘다
func thumbnails(_ images: [RawImage]) async -> [Thumb] {
    let chunkSize = max(1, (images.count + cores - 1) / cores)
    var chunks: [[RawImage]] = []
    var i = images.startIndex
    while i < images.endIndex {
        let j = images.index(i, offsetBy: chunkSize, limitedBy: images.endIndex)
                ?? images.endIndex
        chunks.append(Array(images[i..<j]))
        i = j
    }

    return await withTaskGroup(of: [Thumb].self) { group in
        for chunk in chunks {
            group.addTask { chunk.map(makeThumb) }   // 청크 하나 = Task 하나
        }
        var out: [Thumb] = []
        for await part in group { out += part }
        return out
    }
}

// ❌ images.count가 10,000이면 Task 10,000개 — Task는 값싸지만 공짜는 아니다.
//    협력 풀은 Task를 선점하지 않으므로 스레드 스위칭이 느는 건 아니고,
//    Task별 할당·그룹 부기 비용과 잘게 쪼갠 만큼의 캐시 지역성 손실이 쌓인다

struct Tile {}; struct Pixel {}; struct RawImage {}; struct Thumb {}
func render(_ t: Tile) -> Pixel { Pixel() }
func makeThumb(_ r: RawImage) -> Thumb { Thumb() }

import Foundation

// 전체의 s만큼이 순차라면, 코어를 무한히 늘려도 최대 배속은 1/s를 못 넘는다.
//   순차 5%  → 최대 20배
//   순차 20% → 최대 5배   (코어 32개를 줘도 5배가 천장이다)

func maxSpeedup(sequentialFraction s: Double, cores n: Int) -> Double {
    1.0 / (s + (1.0 - s) / Double(n))
}

func planTarget() {
    for s in [0.05, 0.20, 0.50] {
        let eight = maxSpeedup(sequentialFraction: s, cores: 8)
        let inf   = 1.0 / s
        print(String(format: "순차 %.0f%% → 8코어 %.1f배 · 이론상한 %.1f배",
                     s * 100, eight, inf))
    }
}

// 실무 함의: 목표를 세우기 전에 '순차 구간이 얼마인지' 먼저 잰다.
// 아래처럼 파이프라인을 나눠 각 구간을 측정하면 s가 드러난다.
func measureStages(_ items: [Item]) {
    let clock = ContinuousClock()

    let decode = clock.measure { _ = items.map(decodeOne) }     // 병렬화 가능
    let merge  = clock.measure { _ = mergeAll(items) }          // 순차 (공유 상태)

    print("decode \(decode) · merge \(merge)")
    // merge가 전체의 30%면, decode를 아무리 병렬화해도 3.3배가 천장이다
}

struct Item {}
func decodeOne(_ i: Item) -> Item { i }
func mergeAll(_ i: [Item]) -> Item { Item() }

// 두 연산이 각각 원자적이어도, 그 사이에 다른 스레드가 끼어들 수 있다
if cache[key] == nil {      // (1) 확인
    cache[key] = compute()  // (2) 행동 — 그 사이 다른 스레드가 이미 채웠을 수 있음
}

# Thread Sanitizer는 happens-before 관계를 추적해 data race를 런타임에 검출한다.
# 재현이 어려운 race를 '한 번이라도 실행되면' 잡아낸다.

# ① Xcode에서 켜기
#    Scheme → Test → Diagnostics → Thread Sanitizer ✓
#    (Debug 구성에서만. Release 성능 측정과는 함께 쓰지 않는다)

# ② CI에서 상시로 돌린다 — 여기서 실패하면 머지 불가로 둔다
xcodebuild test \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -enableThreadSanitizer YES

# ③ 로컬에서 SwiftPM 패키지라면
swift test --sanitize=thread

# ⚠️ TSan은 실행 속도를 5~15배 늦추고 메모리를 5~10배 쓴다.
#    전체 스위트가 느려지면 '동시성 테스트 타깃'만 따로 떼어 상시로 돌린다.

# ⚠️ 한계: TSan은 data race(메모리 안전)만 본다.
#    "잔고가 음수가 됐다" 같은 논리 race(race condition)는 못 잡는다.
#    → 그건 아래 ②의 불변식 설계로 막아야 한다.

# ④ Swift 6 strict concurrency는 상당수를 컴파일 타임에 잡는다 — 함께 켠다
#    Package.swift: swiftSettings: [.enableUpcomingFeature("StrictConcurrency")]

import Foundation

// 각 연산이 원자적이어도, 연산 '사이'에 상태가 바뀌면 불변식이 깨진다(TOCTOU).

actor Account {
    private var balance: Int
    init(balance: Int) { self.balance = balance }

    // ❌ 검사와 변경이 갈라져 있다 — 호출자가 이렇게 쓰면 막을 방법이 없다
    func read() -> Int { balance }
    func set(_ v: Int) { balance = v }
    // 호출부: if await a.read() >= 100 { await a.set(await a.read() - 100) }
    //         → 두 await 사이에 다른 출금이 끼어든다

    // ✅ 검사 + 변경을 하나의 메서드 = 하나의 임계구역으로
    func withdraw(_ amount: Int) throws {
        guard balance >= amount else { throw BankError.insufficient }
        balance -= amount           // 사이에 await가 없다 → 끼어들 틈이 없다
    }

    // ✅ 부수효과가 필요하면 '상태 확정 먼저, await 나중'
    func withdrawAndAudit(_ amount: Int) async throws {
        guard balance >= amount else { throw BankError.insufficient }
        balance -= amount                       // ① 먼저 확정하고
        await Audit.shared.record(amount)       // ② 그다음 await
    }
}

enum BankError: Error { case insufficient }
actor Audit {
    static let shared = Audit()
    func record(_ amount: Int) {}
}

// 원자 변수 하나로는 이걸 못 막는다:
// ❌ atomicBalance.subtract(100)  — 음수가 되는 것 자체를 막지 못한다

import Foundation

actor UploadManager {
    private var inFlight: Set<UUID> = []
    private var cancelled: Set<UUID> = []

    // ❌ await 이전에 확인한 것을 이후에도 유효하다고 가정
    func uploadBad(_ id: UUID) async throws {
        guard !cancelled.contains(id) else { return }
        try await network.send(id)          // ⚠️ 여기서 재진입 창이 열린다
        markDone(id)                        // 그사이 취소됐어도 완료 처리된다
    }

    // ✅ await 뒤에서 다시 확인한다
    func upload(_ id: UUID) async throws {
        guard !cancelled.contains(id), inFlight.insert(id).inserted else { return }
        defer { inFlight.remove(id) }

        try await network.send(id)          // 여기서 다른 호출이 끼어들 수 있다

        // ✅ 앞서 확인한 조건을 재검증
        guard !cancelled.contains(id) else { return }
        markDone(id)
    }

    func cancel(_ id: UUID) { cancelled.insert(id) }
    private func markDone(_ id: UUID) {}
}

enum network {
    static func send(_ id: UUID) async throws {}
}

// 규칙으로 만들면 리뷰에서 걸러진다:
//   "actor 메서드 안의 모든 await 뒤에는, 그 앞에서 읽은 상태를 다시 읽었는가?"

let counter = OSAllocatedUnfairLock(initialState: 0)
counter.withLock { $0 += 1 }   // 임계구역: 짧게 · 이 안에서 await·동기 대기 금지

import Foundation
import os

final class MetricsStore {
    private let state = OSAllocatedUnfairLock(initialState: [String: Int]())
    private let semaphore = DispatchSemaphore(value: 0)
    weak var delegate: MetricsDelegate?

    // ❌ 임계구역 안에서 하면 안 되는 세 가지
    func recordBad(_ key: String) {
        state.withLock { dict in
            dict[key, default: 0] += 1
            semaphore.wait()            // ① 동기 대기 — deadlock 씨앗
            delegate?.didUpdate()       // ② 외부 콜백 — 어떤 락을 또 잡을지 모른다
            // ③ await — 애초에 여기선 컴파일도 안 된다(그래서 락과 async는 섞기 어렵다)
        }
    }

    // ✅ 락 안에서는 '순수 계산'만. 부수효과는 밖으로 꺼낸다.
    func record(_ key: String) {
        let snapshot: [String: Int] = state.withLock { dict in
            dict[key, default: 0] += 1
            return dict                 // 필요한 값만 복사해서 나온다
        }
        delegate?.didUpdate(snapshot)   // ✅ 락을 놓은 뒤에 호출
    }
}

protocol MetricsDelegate: AnyObject {
    func didUpdate()
    func didUpdate(_ snapshot: [String: Int])
}

// 이유: 락을 쥔 채 남의 코드를 부르면 그 코드가 무엇을 하는지 알 수 없다.
// 그쪽이 다른 락을 잡으면 잠금 순서가 뒤엉켜 deadlock이 되고,
// 낮은 우선순위 스레드가 락을 쥐고 밀리면 priority inversion이 된다.

import Foundation
import os

// 여러 락이 있으면 '어떤 순서로 잡는가'를 프로젝트 전역 규칙으로 못 박는다.
// 순서가 스레드마다 다르면 그 자체로 deadlock이다.

//   스레드 A: userLock → cartLock
//   스레드 B: cartLock → userLock     ← 서로를 기다리며 영원히 멈춘다

final class Store {
    // ── 잠금 순서 규칙: 반드시 user → cart 순서로만 잡는다 (역순 금지) ──

    /// 보호 범위: currentUser, loginState
    private let userLock = OSAllocatedUnfairLock(initialState: UserState())

    /// 보호 범위: items, coupon  (userLock을 잡은 뒤에만 잡을 수 있다)
    private let cartLock = OSAllocatedUnfairLock(initialState: CartState())

    // ✅ 규칙을 지킨 접근
    func applyMemberDiscount() {
        userLock.withLock { user in
            let isMember = user.isMember          // inout 파라미터를 클로저로 캡처하지 않는다
            cartLock.withLock { cart in           // (Swift 6에서는 캡처 시 컴파일 에러)
                cart.discount = isMember ? 0.1 : 0
            }
        }
    }

    // ✅ 더 나은 방법: 애초에 락을 하나로 합쳐 순서 문제를 없앤다
    private struct Combined { var user = UserState(); var cart = CartState() }
    private let combined = OSAllocatedUnfairLock(initialState: Combined())

    func applyBetter() {
        combined.withLock { state in          // 클로저는 inout 값 '하나'를 받는다
            state.cart.discount = state.user.isMember ? 0.1 : 0
        }
    }
}

struct UserState { var isMember = false }
struct CartState { var discount: Double = 0 }

// 락이 둘 이상 필요해지는 순간이 "이 상태들을 하나의 actor로 합쳐야 하나?"를
// 물어볼 시점이다.

import Foundation
import os

// os_unfair_lock은 struct다. 값으로 복사되면 서로 다른 락이 되어 보호가 무효가 된다.

// ❌ 이 코드는 컴파일도 되고 지금은 대개 동작하지만, 언어가 아무것도 보장하지 않는다
final class BrokenCache {
    private var lock = os_unfair_lock()      // struct
    private var storage: [String: Int] = [:]

    func set(_ v: Int, _ k: String) {
        // &lock의 inout-to-pointer 변환이 주는 포인터는 '이 호출 동안만' 유효하고
        // 주소 안정성이 보장되지 않는다. withUnsafeMutablePointer로 감싸도 똑같다 —
        // 그건 해법이 아니다. 아래 ①·②처럼 주소를 고정해야 한다
        os_unfair_lock_lock(&lock)
        storage[k] = v
        os_unfair_lock_unlock(&lock)
    }
}

// ✅ ① 가장 안전 — 복사 사고가 구조적으로 불가능한 래퍼 (iOS 16+)
final class SafeCache: @unchecked Sendable {
    // 모든 storage 접근이 이 락을 통과한다 — 아래 메서드가 유일한 진입점
    private let state = OSAllocatedUnfairLock(initialState: [String: Int]())

    func set(_ v: Int, _ k: String) { state.withLock { $0[k] = v } }
    func get(_ k: String) -> Int?   { state.withLock { $0[k] } }
}

// ✅ ② 하위 버전을 지원해야 하면 포인터로 고정한다
final class LegacyCache {
    private let lock: UnsafeMutablePointer<os_unfair_lock>
    private var storage: [String: Int] = [:]

    init() {
        lock = .allocate(capacity: 1)
        lock.initialize(to: os_unfair_lock())   // 주소가 고정된다
    }
    deinit { lock.deinitialize(count: 1); lock.deallocate() }

    func set(_ v: Int, _ k: String) {
        os_unfair_lock_lock(lock); defer { os_unfair_lock_unlock(lock) }
        storage[k] = v
    }
}

// 같은 이유로 NSLock(class)은 복사 문제가 없지만 os_unfair_lock보다 느리다.

import Foundation

let serial = DispatchQueue(label: "com.app.db")

// ❌ serial queue라고 스레드가 고정될 거라 믿는 코드
final class BrokenSession {
    private var threadName: String?

    func begin() {
        serial.async {
            self.threadName = Thread.current.name   // 이번엔 "Thread-7"
        }
    }

    func commit() {
        serial.async {
            // 다음 블록은 전혀 다른 스레드에서 돌 수 있다 → 항상 불일치
            assert(self.threadName == Thread.current.name)   // 💥 깨진다
        }
    }
}

// ✅ 보장되는 것은 '순서'와 '상호배제'뿐이다. 그걸 전제로 설계한다.
actor DBSession {
    private var isOpen = false
    func begin() { isOpen = true }
    func commit() { precondition(isOpen); isOpen = false }
}

// 유일한 예외: main queue = main thread (UI 프레임워크 요구 때문에 고정된다)
@MainActor
func updateUI() {
    assert(Thread.isMainThread)      // ✅ 이건 항상 참이다
}

// ⚠️ 스레드에 묶인 레거시 API(일부 C 라이브러리, OpenGL 컨텍스트 등)를 써야 하면
//    GCD가 아니라 전용 Thread + RunLoop를 직접 만들어야 한다.

import Foundation

// "지금 이 큐 위인가?"를 스레드 신원으로 판단하면 틀린다. 큐에 표식을 달아 확인한다.

final class Database {
    private let queue = DispatchQueue(label: "com.app.db")
    private static let key = DispatchSpecificKey<UInt8>()
    private let marker: UInt8 = 1

    init() {
        queue.setSpecific(key: Self.key, value: marker)   // ✅ 큐에 표식을 붙인다
    }

    private var isOnQueue: Bool {
        DispatchQueue.getSpecific(key: Self.key) == marker
    }

    // ✅ 이미 큐 위면 그냥 실행, 아니면 진입 — 재진입 self-deadlock을 피한다
    func perform<T>(_ work: () throws -> T) rethrows -> T {
        isOnQueue ? try work() : try queue.sync(execute: work)
    }

    // ✅ 진입점 방어
    func assertOnQueue() {
        dispatchPrecondition(condition: .onQueue(queue))
    }
}

// 메인 한정이면 이게 가장 단순하다
func requireMain() {
    dispatchPrecondition(condition: .onQueue(.main))
    // 또는 assert(Thread.isMainThread)
}

// Swift Concurrency에서는 컴파일러가 대신 검사해 준다 — 런타임 확인이 필요 없다
@MainActor func onMainOnly() {}

import Foundation

// TLS(thread-local storage)는 '스레드 = 작업 단위'일 때만 성립한다.
// GCD·Swift Concurrency에서는 스레드가 여러 작업 사이를 오간다.

let queue = DispatchQueue(label: "com.app.tx")

// ❌ 트랜잭션 컨텍스트를 TLS에 — 다음 작업이 남은 값을 주워 간다
func beginBad(_ tx: String) {
    queue.async {
        Thread.current.threadDictionary["tx"] = tx
        step1()
    }
}
func step1() {
    let tx = Thread.current.threadDictionary["tx"] as? String
    print("tx: \(tx ?? "없음")")     // 다른 작업의 tx가 보일 수 있다
}

// ✅ ① 컨텍스트를 값으로 들고 다닌다
struct Transaction { let id: String }

func begin(_ tx: Transaction) {
    queue.async { step1(tx) }
}
func step1(_ tx: Transaction) { print("tx: \(tx.id)") }

// ✅ ② Swift Concurrency라면 task-local — Task 스코프라 스레드와 무관하다
enum TxContext {
    @TaskLocal static var current: Transaction?
}

func beginAsync(_ tx: Transaction) async {
    await TxContext.$current.withValue(tx) {
        await deepStep()
    }
}
func deepStep() async {
    print("tx: \(TxContext.current?.id ?? "없음")")   // ✅ 항상 이 Task의 값
}

import Foundation

// GCD 전역 큐의 워커 스레드는 유한하다(대략 64개/QoS). 블로킹 작업으로 다 채우면
// 새 작업이 스레드를 못 받아 굶고, 최악의 경우 교착으로 보인다.

// ❌ 100개를 한꺼번에 던진다 — 각각이 스레드를 붙잡고 대기한다
func downloadAllBad(_ urls: [URL]) {
    for url in urls {
        DispatchQueue.global().async {
            _ = try? Data(contentsOf: url)     // 동기 블로킹
        }
    }
}

// 스레드 수를 실제로 관찰해 보면 폭증이 눈에 보인다
func logThreadCount(_ tag: String) {
    var count: mach_msg_type_number_t = 0
    var threads: thread_act_array_t?
    if task_threads(mach_task_self_, &threads, &count) == KERN_SUCCESS {
        print("[\(tag)] 스레드 \(count)개")
        if let t = threads {
            vm_deallocate(mach_task_self_, vm_address_t(UInt(bitPattern: t)),
                          vm_size_t(Int(count) * MemoryLayout<thread_t>.size))
        }
    }
}

// ✅ 애초에 블로킹을 안 하는 API로 바꾸는 게 1순위다
func downloadAll(_ urls: [URL]) async throws -> [Data] {
    try await withThrowingTaskGroup(of: Data.self) { group in
        for url in urls {
            group.addTask { try await URLSession.shared.data(from: url).0 }
        }
        var out: [Data] = []
        for try await d in group { out.append(d) }
        return out
    }
}

import Foundation

// 레거시 C 라이브러리처럼 정말 블로킹뿐이라면, 그 블로킹을 '가둔다'.

// ✅ ① 전용 serial queue — 동시 실행 1개로 고정
final class LegacyDecoder {
    private let queue = DispatchQueue(label: "com.app.decode", qos: .utility)

    func decode(_ data: Data, completion: @escaping (Image) -> Void) {
        queue.async {
            let image = blockingDecode(data)     // 이 큐 하나만 붙잡는다
            completion(image)
        }
    }
}

// ✅ ② 동시 실행 개수를 명시적으로 제한하는 풀
final class BoundedPool {
    private let semaphore: DispatchSemaphore
    private let queue: DispatchQueue

    init(limit: Int, label: String) {
        semaphore = DispatchSemaphore(value: limit)
        queue = DispatchQueue(label: label, qos: .utility, attributes: .concurrent)
    }

    func run(_ work: @escaping () -> Void) {
        semaphore.wait()                   // ✅ 제출 '전'에 자리를 확보한다 — 워커를 붙잡지 않는다
        queue.async {
            defer { self.semaphore.signal() }
            work()
        }
    }
}
// ⚠️ wait를 queue.async 안에 넣으면 정반대가 된다 — 대기하는 블록마다 워커를 하나씩
//    붙잡아 그 자체로 thread explosion이다(limit 4에 100개 제출 → 실측 71스레드).

let decodePool = BoundedPool(limit: ProcessInfo.processInfo.activeProcessorCount,
                             label: "com.app.decode.pool")

// ✅ ③ async 세계라면 세마포어 대신 이 패턴 (스레드를 막지 않는다)
actor Limiter {
    private let limit: Int
    private var running = 0
    private var waiters: [CheckedContinuation<Void, Never>] = []

    init(limit: Int) { self.limit = limit }

    func run<T>(_ work: () async throws -> T) async rethrows -> T {
        if running >= limit {
            await withCheckedContinuation { waiters.append($0) }
        }
        running += 1
        defer {
            running -= 1
            if !waiters.isEmpty { waiters.removeFirst().resume() }
        }
        return try await work()
    }
}

struct Image {}
func blockingDecode(_ d: Data) -> Image { Image() }

import Foundation

// QoS는 '얼마나 급한가'를 시스템에 알려 주는 신호다. 잘못 주면
// 우선순위 역전(낮은 QoS가 높은 QoS를 막음)이나 전력 낭비가 생긴다.

// ✅ 사용자가 화면에서 기다린다 → .userInitiated
func loadCurrentScreen() {
    DispatchQueue.global(qos: .userInitiated).async {
        let data = fetchSync()
        DispatchQueue.main.async { render(data) }
    }
}

// ✅ 곧 필요하지만 지금 기다리진 않는다 → .utility (E 코어로 갈 수 있다)
func prefetchNextPage() {
    Task(priority: .utility) { await prefetch() }
}

// ✅ 사용자가 전혀 모르는 뒷정리 → .background
let cleanup = DispatchQueue(label: "com.app.cleanup", qos: .background)

// ❌ 전부 .userInitiated로 올리면 우선순위가 의미를 잃고 전력만 더 쓴다
// ❌ 반대로 UI 대기 작업을 .background로 두면 E 코어에서 한참 걸린다

// ⚠️ 우선순위 역전: 높은 QoS가 낮은 QoS의 결과를 기다리면 시스템이
//    낮은 쪽을 일시적으로 승격해 준다(priority donation). 다만 승격이
//    통하지 않는 경로(예: 세마포어로 막아 둔 경우)가 있으니
//    "높은 QoS가 낮은 QoS를 기다리는 구조" 자체를 피하는 게 낫다.

// Swift Concurrency에서는 Task 우선순위가 같은 역할을 하고,
// 자식 Task에 자동으로 상속된다.
func structured() async {
    await withTaskGroup(of: Void.self) { group in
        group.addTask(priority: .utility) { await prefetch() }
    }
}

func fetchSync() -> Data { Data() }
func render(_ d: Data) {}
func prefetch() async {}

// 이미 Main Thread(= Main Queue의 실행 흐름) 위에서
DispatchQueue.main.sync {
    print("절대 실행되지 않음")   // 여기 도달 못 함 → 앱 정지
}

import Foundation

final class Cache {
    private let queue = DispatchQueue(label: "com.app.cache")
    private var storage: [String: Data] = [:]

    // ❌ 이미 이 큐 위에서 호출되면 즉시 self-deadlock — 앱이 그대로 멈춘다
    func valueUnsafe(_ key: String) -> Data? {
        queue.sync { storage[key] }
    }

    // ✅ 개발 중에 크래시로 잡는다 — 배포 후 정지보다 훨씬 낫다
    func value(_ key: String) -> Data? {
        dispatchPrecondition(condition: .notOnQueue(queue))
        return queue.sync { storage[key] }
    }

    // ✅ 더 나은 방법: 재진입을 구조적으로 허용한다 (queue-specific key)
    private static let key = DispatchSpecificKey<UInt8>()
    init() { queue.setSpecific(key: Self.key, value: 1) }

    func valueReentrant(_ key: String) -> Data? {
        if DispatchQueue.getSpecific(key: Self.key) == 1 {
            return storage[key]              // 이미 큐 위 → 직접 접근
        }
        return queue.sync { storage[key] }   // 밖 → 진입
    }
}

// 가장 흔한 사고: 메인 스레드에서 메인 큐로 sync
func classicDeadlock() {
    DispatchQueue.main.sync {        // 💥 메인에서 부르면 영구 정지
        print("절대 실행되지 않는다")
    }
}

// ✅ 이미 메인인지 확인하고 분기
func onMain(_ work: @escaping () -> Void) {
    if Thread.isMainThread { work() } else { DispatchQueue.main.async(execute: work) }
}

import Foundation

// "값을 돌려받아야 하니 sync를 쓴다"는 대부분 구조를 바꿔 없앨 수 있다.

// ❌ 동기 게터 — 호출자가 어디서 부르는지에 따라 교착 위험이 따라다닌다
final class SyncStore {
    private let queue = DispatchQueue(label: "com.app.store")
    private var value = 0
    func read() -> Int { queue.sync { value } }
}

// ✅ ① actor — 기다림이 suspend라서 스레드를 붙잡지 않는다. 교착이 생길 자리가 없다.
actor Store {
    private var value = 0
    func read() -> Int { value }
    func write(_ v: Int) { value = v }
}

// ✅ ② 레거시 콜백 API를 감싸야 하면 continuation
func legacyLoad(_ done: @escaping (Data) -> Void) {}

func load() async -> Data {
    await withCheckedContinuation { cont in
        legacyLoad { data in cont.resume(returning: data) }
    }
}

// ✅ ③ 실패할 수 있으면 throwing 버전
enum LoadError: Error { case failed }
func legacyLoadMaybe(_ done: @escaping (Data?) -> Void) {}

func loadThrowing() async throws -> Data {
    try await withCheckedThrowingContinuation { cont in
        legacyLoadMaybe { data in
            if let data { cont.resume(returning: data) }
            else { cont.resume(throwing: LoadError.failed) }
        }
    }
}

// ⚠️ continuation은 정확히 한 번만 resume해야 한다.
//    두 번 부르면 크래시, 한 번도 안 부르면 그 Task가 영원히 깨어나지 않는다.
//    withCheckedContinuation은 이 실수를 런타임에 잡아 준다(디버그 빌드).

import Foundation
import os

// 큐와 락을 함께 쓰면 '획득 순서'가 두 종류로 늘어난다. 규칙을 정하지 않으면
// 한쪽은 큐→락, 다른 쪽은 락→큐로 잡아 교착이 난다.

let ioQueue = DispatchQueue(label: "com.app.io")
let stateLock = OSAllocatedUnfairLock(initialState: 0)

// ❌ 스레드 A: 락을 쥔 채 큐로 진입
func badA() {
    stateLock.withLock { _ in
        ioQueue.sync { print("A") }      // 락 → 큐
    }
}

// ❌ 스레드 B: 큐 위에서 락을 잡으려 함
func badB() {
    ioQueue.async {
        stateLock.withLock { _ in print("B") }   // 큐 → 락
    }
}
// A가 락을 쥐고 큐를 기다리고, B가 큐를 쥐고 락을 기다리면 영원히 멈춘다.

// ✅ 프로젝트 전역 규칙: "큐에 먼저 진입하고, 그 안에서만 락을 잡는다"
func good() {
    ioQueue.async {
        stateLock.withLock { $0 += 1 }   // 항상 큐 → 락
    }
}

// ✅ 더 나은 해법: 둘 중 하나를 없앤다. 큐가 이미 직렬화를 해 주면 락은 불필요하다.
final class Counter {
    private let queue = DispatchQueue(label: "com.app.counter")   // serial
    private var value = 0                                          // 락 없음
    func increment() { queue.async { self.value += 1 } }
}

// 규칙은 코드 주석이 아니라 CI 린트나 아키텍처 문서에 남겨야 지켜진다.

import Foundation

// cooperative pool의 스레드 수는 대략 코어 수다. 그중 하나를 CPU 루프가
// 독점하면 다른 Task가 그만큼 못 돈다. 전부 독점하면 앱이 멈춘 것처럼 보인다.

// ❌ 양보 없는 CPU 루프
func renderAllBad(_ frames: [Frame]) {
    Task {
        for f in frames { heavyRender(f) }    // 끝날 때까지 워커 하나를 붙잡는다
    }
}

// ✅ ① 주기적으로 양보한다 — 간단하지만 여전히 협력 풀을 쓴다
func renderAll(_ frames: [Frame]) {
    Task {
        for (i, f) in frames.enumerated() {
            heavyRender(f)
            if i % 50 == 0 { await Task.yield() }   // 다른 Task에 차례를 준다
        }
    }
}

// ✅ ② 더 나은 방법: 긴 CPU 작업은 협력 풀 밖 전용 큐로 내보낸다
private let cpuQueue = DispatchQueue(label: "com.app.render",
                                     qos: .userInitiated,
                                     attributes: .concurrent)

func render(_ frame: Frame) async -> Image {
    await withCheckedContinuation { cont in
        cpuQueue.async { cont.resume(returning: heavyRender(frame)) }
    }
}

// ✅ ③ 취소도 함께 챙긴다 — 긴 루프는 취소 확인 지점이 필요하다
func renderCancellable(_ frames: [Frame]) async throws -> [Image] {
    var out: [Image] = []
    for f in frames {
        try Task.checkCancellation()
        out.append(await render(f))
    }
    return out
}

struct Frame {}; struct Image {}
@discardableResult func heavyRender(_ f: Frame) -> Image { Image() }

import Foundation

// Task는 await를 지날 때마다 다른 스레드에서 재개될 수 있다.
// 스레드 신원에 의존하는 코드와 섞으면 조용히 깨진다.

// ❌ await 전후로 같은 스레드일 거라 가정
func brokenFlow() async throws {
    let before = Thread.current
    try await Task.sleep(for: .milliseconds(1))
    let after = Thread.current
    assert(before === after)          // 💥 보장되지 않는다
}
// ⚠️ Swift 6에서는 Thread.current를 async 컨텍스트에서 쓰는 것 자체가
//    컴파일 에러다 — 언어가 "스레드에 의존하지 마라"를 강제하는 셈이다

// ❌ TLS에 값을 넣고 await 뒤에 읽기
func brokenContext() async {
    Thread.current.threadDictionary["k"] = "v"
    await someAsyncWork()
    let v = Thread.current.threadDictionary["k"]   // nil일 수 있다
    print(v ?? "사라짐")
}

// ✅ 보장되는 것은 스레드가 아니라 'actor 격리'다
@MainActor
func safeFlow() async {
    assert(Thread.isMainThread)
    await someAsyncWork()
    assert(Thread.isMainThread)       // ✅ MainActor라면 이건 참이다
}

// ✅ 컨텍스트가 필요하면 task-local (Task 스코프라 await를 넘어 유지된다)
enum Ctx { @TaskLocal static var traceID = "-" }

func tracedWork() async {
    await Ctx.$traceID.withValue(UUID().uuidString) {
        await someAsyncWork()
        print(Ctx.traceID)            // ✅ await 뒤에도 같은 값
    }
}

// ⚠️ 스레드에 묶인 레거시(OpenGL 컨텍스트, 일부 C 라이브러리)를 써야 하면
//    Task로 감싸지 말고 전용 Thread나 serial queue에 가둔 뒤
//    continuation으로 노출한다.

func someAsyncWork() async {}

import Foundation

// Task.detached는 부모의 취소·우선순위·actor 격리·task-local을 전부 끊는다.
// "그게 필요해서" 쓰는 게 아니라면 구조적 동시성이 항상 낫다.

// ✅ ① 고정 개수 → async let
func loadScreen() async throws -> (Profile, [Post]) {
    async let profile = api.profile()
    async let posts = api.posts()
    return try await (profile, posts)
    // 어느 하나가 throw하면 나머지는 자동 취소된다
}

// ✅ ② 가변 개수 → TaskGroup
func loadAll(_ ids: [String]) async throws -> [Post] {
    try await withThrowingTaskGroup(of: Post.self) { group in
        for id in ids { group.addTask { try await api.post(id) } }
        var out: [Post] = []
        for try await p in group { out.append(p) }
        return out
    }
    // 그룹을 벗어나면 남은 자식이 모두 취소·정리된다
}

// ✅ ③ 화면 수명에 묶인 작업 → Task { }  (부모 컨텍스트 상속)
@MainActor
final class ViewModel {
    private var loadTask: Task<Void, Never>?

    func onAppear() {
        loadTask = Task {                 // MainActor 격리·우선순위를 상속
            await self.refresh()
        }
    }
    func onDisappear() { loadTask?.cancel() }
    private func refresh() async {}
}

// ⚠️ detached가 정당한 경우: 호출자 수명과 무관하게 끝까지 가야 하는 작업
func fireAndForgetLog(_ event: String) {
    Task.detached(priority: .background) {
        try? await Analytics.send(event)   // 화면이 닫혀도 전송은 마친다
    }
}
// 이 경우에도 "부모 취소가 전파되지 않는다"를 팀 규칙으로 명시해 둔다.

struct Profile {}; struct Post {}
enum api {
    static func profile() async throws -> Profile { Profile() }
    static func posts() async throws -> [Post] { [] }
    static func post(_ id: String) async throws -> Post { Post() }
}
enum Analytics { static func send(_ e: String) async throws {} }

// ❌ async 안에서 실제 스레드를 막는다 → 협력 풀 기아 위험
func loadBad() async -> Data {
    let sema = DispatchSemaphore(value: 0)
    var result = Data()
    legacyLoad { data in result = data; sema.signal() }
    sema.wait()                     // 스레드 점유
    return result
}

// ✅ suspend: 스레드를 반납하고 콜백에서 재개
func loadGood() async -> Data {
    await withCheckedContinuation { cont in
        legacyLoad { data in cont.resume(returning: data) }
    }
}

import Foundation

// await는 스레드를 반납하지만, 그 안에서 블로킹 API를 부르면 스레드가 그대로 막힌다.
// 협력 풀은 스레드 수가 코어 수라서, GCD 시절보다 오히려 더 치명적이다.

// ❌ 세 가지 대표적인 실수
func badPatterns() async {
    // ① 세마포어로 비동기를 동기처럼 기다리기
    let sema = DispatchSemaphore(value: 0)
    legacyLoad { _ in sema.signal() }
    sema.wait()                                  // 워커 스레드 하나 사망

    // ② 동기 I/O
    _ = try? Data(contentsOf: URL(fileURLWithPath: "/big"))

    // ③ Thread.sleep
    Thread.sleep(forTimeInterval: 1)
}

// ✅ 각각의 올바른 대응
func goodPatterns() async throws {
    // ① continuation으로 감싼다 — 스레드를 반납한 채 기다린다
    let data = await withCheckedContinuation { cont in
        legacyLoad { cont.resume(returning: $0) }
    }
    _ = data

    // ② async I/O API를 쓴다
    let (bytes, _) = try await URLSession.shared.bytes(from: URL(string: "https://x")!)
    for try await _ in bytes {}

    // ③ Task.sleep — 취소도 인지한다
    try await Task.sleep(for: .seconds(1))
}

// 굶주림을 확인하는 방법: 협력 풀 워커가 다 막히면
// 아래처럼 단순한 Task조차 실행이 한참 지연된다
func canary() {
    Task {
        let t = ContinuousClock.now
        await Task.yield()
        print("yield 지연: \(ContinuousClock.now - t)")   // 수십 ms면 굶주림 의심
    }
}

func legacyLoad(_ done: @escaping (Data) -> Void) {}

import Foundation

// 정말 블로킹뿐인 C API는 없앨 수 없다. 대신 '협력 풀 밖'에 가둔다.

// ✅ 전용 큐에 격리하고 async 인터페이스로만 노출한다
actor LegacyBridge {
    // 협력 풀과 분리된 자체 큐 — 여기가 막혀도 Swift Concurrency는 멀쩡하다
    private let queue = DispatchQueue(label: "com.app.legacy", qos: .userInitiated)

    func decode(_ input: Data) async throws -> Data {
        try await withCheckedThrowingContinuation { cont in
            queue.async {
                do    { cont.resume(returning: try blockingDecode(input)) }
                catch { cont.resume(throwing: error) }
            }
        }
    }
}

// ✅ 동시 실행이 필요하면 concurrent 큐 + 개수 제한
final class BlockingPool {
    private let queue = DispatchQueue(label: "com.app.blocking",
                                      qos: .utility, attributes: .concurrent)
    private let semaphore: DispatchSemaphore

    init(limit: Int) { semaphore = DispatchSemaphore(value: limit) }

    func run<T>(_ work: @escaping () throws -> T) async throws -> T {
        semaphore.wait()                 // ✅ 큐에 넣기 '전'에 기다린다
        return try await withCheckedThrowingContinuation { cont in
            queue.async {
                defer { self.semaphore.signal() }
                cont.resume(with: Result { try work() })
            }
        }
    }
}

// ⚠️ 세마포어는 큐에 넣기 '전'에 기다려야 한다. 안에서 기다리면 대기 블록마다 GCD
//    워커를 하나씩 붙잡아 전역 워커 풀에 thread explosion이 난다 — 커스텀 concurrent
//    큐도 '전용 풀'이 아니라 같은 전역 워커 풀을 공유하기 때문이다.
//    이렇게 해야 협력 풀도, GCD 풀도 굶지 않는다 — 그게 핵심이다.

func blockingDecode(_ d: Data) throws -> Data { d }

import Foundation

// ❌ Thread.sleep — 스레드를 통째로 막고, 취소도 인지하지 못한다
func retryBad() async {
    for _ in 0..<3 {
        Thread.sleep(forTimeInterval: 2)     // 워커 하나가 2초간 죽는다
    }
}

// ✅ Task.sleep — suspend라 스레드를 반납하고, 취소 시 즉시 throw한다
func retry() async throws {
    for attempt in 1...3 {
        do { return try await send() }
        catch {
            try await Task.sleep(for: .seconds(pow(2, Double(attempt))))
            // 취소되면 여기서 CancellationError가 던져져 루프가 즉시 끝난다
        }
    }
}

// ✅ 테스트 가능하게 만들려면 Clock을 주입받는다
struct Backoff<C: Clock> where C.Duration == Duration {
    let clock: C

    func wait(attempt: Int) async throws {
        let base = min(pow(2.0, Double(attempt)), 30)
        let jittered = base * Double.random(in: 0.5...1.5)
        try await clock.sleep(for: .seconds(jittered))
    }
}

// 프로덕션
let real = Backoff(clock: ContinuousClock())

// ⚠️ Task.sleep은 '최소 지연'을 보장할 뿐 정확한 시각을 보장하지 않는다.
//    tolerance를 명시하면 시스템이 타이머를 묶어 전력을 아낀다.
func lowPowerWait() async throws {
    try await ContinuousClock().sleep(for: .seconds(60), tolerance: .seconds(5))
}

func send() async throws {}

actor Bank {
    var balance = 100
    func withdraw(_ amount: Int) async {
        guard balance >= amount else { return }   // (1) 확인
        await notifyAudit()                        // await → 다른 호출이 끼어들 수 있음
        balance -= amount                          // (2) 그 사이 balance가 바뀌었을 수 있다
    }
}

import UIKit

// ❌ 런타임에 확인하는 방식 — 놓치면 크래시나 미정의 동작
final class OldViewModel {
    var onUpdate: ((String) -> Void)?
    func load() {
        URLSession.shared.dataTask(with: url) { data, _, _ in
            self.onUpdate?("완료")        // 백그라운드 스레드에서 UI 갱신 💥
        }.resume()
    }
    private let url = URL(string: "https://x")!
}

// ✅ @MainActor로 격리하면 컴파일러가 강제한다
@MainActor
final class ProfileViewModel: ObservableObject {
    @Published private(set) var name = ""
    @Published private(set) var isLoading = false

    func load() async {
        isLoading = true                       // 메인에서 실행
        defer { isLoading = false }

        // await 동안 메인 스레드는 반납된다 — UI는 계속 반응한다
        let fetched = await api.name()

        name = fetched                         // 재개 시 다시 메인에서
    }
}

// ✅ 타입 전체가 아니라 일부만 격리할 수도 있다
final class ImageLoader {
    nonisolated func fetch(_ url: URL) async throws -> Data {
        try await URLSession.shared.data(from: url).0    // 어느 스레드든 OK
    }

    @MainActor
    func apply(_ data: Data, to view: UIImageView) {     // 여기만 메인 강제
        view.image = UIImage(data: data)
    }
}

// ✅ 프로토콜·클로저 경계에도 붙일 수 있다
@MainActor protocol ViewUpdating { func refresh() }

enum api { static func name() async -> String { "" } }

import Foundation

actor ImageCache {
    private var cache: [URL: Data] = [:]
    private var loading: Set<URL> = []

    // ❌ await 사이에 다른 호출이 끼어들어 같은 URL을 두 번 받아온다
    func imageBad(_ url: URL) async throws -> Data {
        if let hit = cache[url] { return hit }
        let data = try await download(url)     // ⚠️ 재진입 창
        cache[url] = data
        return data
    }
    // 동시에 5번 호출되면 5번 다운로드된다 — 캐시가 무의미해진다

    // ✅ 진행 중임을 상태로 남기고, await 뒤에 다시 확인한다
    private var inFlight: [URL: Task<Data, Error>] = [:]

    func image(_ url: URL) async throws -> Data {
        if let hit = cache[url] { return hit }
        if let running = inFlight[url] { return try await running.value }  // 합류

        let task = Task { try await download(url) }
        inFlight[url] = task
        defer { inFlight[url] = nil }

        let data = try await task.value

        // ✅ await 뒤 재확인 — 그사이 누가 이미 채웠을 수도 있다
        if let hit = cache[url] { return hit }
        cache[url] = data
        return data
    }

    private func download(_ url: URL) async throws -> Data {
        try await URLSession.shared.data(from: url).0
    }
}

// 규칙: actor 메서드에서 await를 볼 때마다
//   "이 앞에서 읽은 값이 뒤에서도 유효한가?"를 반드시 물어본다.

import Foundation

// actor는 락이 아니다. await마다 재진입 창이 열리므로
// "actor 안에 넣었으니 이 메서드 전체가 원자적"이라는 기대는 틀렸다.

actor OrderProcessor {
    private var stock: [String: Int] = [:]

    // ❌ 긴 메서드 안에 await가 여러 개 — 매 지점마다 상태가 바뀔 수 있다
    func processBad(_ order: Order) async throws {
        guard stock[order.sku, default: 0] >= order.qty else { throw ShopError.soldOut }
        await payment.charge(order)                 // 재진입 창 ①
        await shipping.reserve(order)               // 재진입 창 ②
        stock[order.sku]! -= order.qty              // 이미 남이 다 팔았을 수 있다
    }

    // ✅ 상태 변경은 await 없는 짧은 구간에서 원자적으로 끝낸다
    func reserve(_ order: Order) throws {
        let left = stock[order.sku, default: 0]
        guard left >= order.qty else { throw ShopError.soldOut }
        stock[order.sku] = left - order.qty         // await 없음 → 원자적
    }

    func release(_ order: Order) {
        stock[order.sku, default: 0] += order.qty
    }
}

// 긴 흐름은 actor '밖'에서 조립한다 — actor는 상태 보관만 담당
func placeOrder(_ order: Order, in processor: OrderProcessor) async throws {
    try await processor.reserve(order)              // ① 원자적으로 선점
    do {
        await payment.charge(order)                 // ② 느린 작업은 밖에서
        await shipping.reserve(order)
    } catch {
        await processor.release(order)              // ③ 실패하면 보상
        throw error
    }
}

struct Order { let sku: String; let qty: Int }
enum ShopError: Error { case soldOut }
enum payment { static func charge(_ o: Order) async {} }
enum shipping { static func reserve(_ o: Order) async {} }

import Foundation

// ✅ 값 타입이고 내부가 전부 Sendable이면 컴파일러가 자동으로 Sendable을 추론한다
//    단, 자동 추론은 non-public 타입(과 frozen public 타입)에만 적용된다 —
//    public non-frozen 타입은 아래처럼 명시적으로 선언해야 한다
struct FeedItem: Sendable, Identifiable {
    let id: UUID
    let title: String
    let createdAt: Date
    let tags: [String]           // Array<String>도 Sendable
}

// ✅ 참조 타입이어야 한다면 '불변'으로 만들어 Sendable을 정당화한다
final class Configuration: Sendable {
    let baseURL: URL
    let timeout: TimeInterval
    init(baseURL: URL, timeout: TimeInterval) {
        self.baseURL = baseURL
        self.timeout = timeout
    }
    // 전부 let이라 만들어진 뒤에는 아무도 바꿀 수 없다 → 공유해도 안전
}

// ❌ var가 하나라도 있으면 Sendable이 아니다 (컴파일 에러로 잡힌다)
final class MutableConfig {
    var baseURL: URL = URL(string: "https://x")!
}
// func send(_ c: MutableConfig) async {}   // 경계를 넘기려 하면 경고/에러

// ✅ 변경이 필요하면 '새 값을 만드는' 방식으로 (불변 유지)
extension Configuration {
    func with(timeout: TimeInterval) -> Configuration {
        Configuration(baseURL: baseURL, timeout: timeout)
    }
}

// ✅ enum도 페이로드가 Sendable이면 자동 Sendable
enum LoadState: Sendable {
    case idle
    case loading
    case loaded([FeedItem])
    case failed(String)          // Swift 6에서는 Error가 Sendable을 상속하므로 case failed(any Error)도 가능하다
}

import Foundation
import os

// @unchecked는 "컴파일러 검사를 끄겠다"는 선언이다.
// 실제 동기화가 없으면 그냥 거짓 약속이고, 오히려 더 위험하다.

// ❌ 경고를 없애려고 붙인 것 — 아무것도 보호하지 않는다
final class BadCounter: @unchecked Sendable {
    var value = 0                        // 동기화 없음. 그냥 data race.
}

// ✅ 근거를 주석으로 남기고, 실제로 락을 통과시킨다
/// 스레드 안전성: 모든 저장 프로퍼티 접근이 `state` 락을 통과한다.
/// 아래 세 메서드가 유일한 진입점이며, 내부 상태를 외부로 노출하지 않는다.
/// 가변 상태를 통째로 락 안에 넣었으므로 @unchecked 없이 검증된 Sendable이 된다.
final class MetricsBuffer: Sendable {
    private let state = OSAllocatedUnfairLock(initialState: [String: Int]())

    func increment(_ key: String) {
        state.withLock { $0[key, default: 0] += 1 }
    }

    func snapshot() -> [String: Int] {
        state.withLock { $0 }            // 복사본을 돌려준다 (내부 참조 유출 금지)
    }

    func reset() {
        state.withLock { $0.removeAll() }
    }
}

// ✅ 더 나은 선택지가 있으면 그쪽을 먼저 검토한다
actor MetricsActor {                     // @unchecked가 아예 필요 없다
    private var counts: [String: Int] = [:]
    func increment(_ key: String) { counts[key, default: 0] += 1 }
    func snapshot() -> [String: Int] { counts }
}

// @unchecked가 정당한 경우는 사실상 둘뿐이다:
//   ① var 저장 프로퍼티를 별도 락으로 지켜 컴파일러가 그 관계를 증명할 수 없는 타입
//      (상태를 OSAllocatedUnfairLock·Mutex 안에 넣으면 @unchecked 없이 검증을 통과한다)
//   ② 불변인데 컴파일러가 증명하지 못하는 경우(예: C 타입 래핑)

import Foundation

// 레거시 모듈을 한 번에 Sendable로 만들 수는 없다. 경계를 그어 단계적으로 옮긴다.

// ① 아직 동시성을 모르는 모듈은 @preconcurrency로 들여온다
//    → 그 모듈에서 오는 타입에 대한 Sendable 경고를 유예한다
@preconcurrency import Foundation

// ② 경계에서 '내 값 타입'으로 즉시 변환한다 — 레거시 참조가 안으로 새지 않는다
final class LegacyUser {                 // 남이 만든 가변 클래스
    var name: String = ""
    var email: String = ""
}

struct User: Sendable {                  // ✅ 내 도메인 모델은 값 타입
    let name: String
    let email: String

    init(_ legacy: LegacyUser) {         // 경계에서 한 번만 복사
        name = legacy.name
        email = legacy.email
    }
}

// ③ 레거시 API를 감싸는 얇은 어댑터를 두고, 그 밖으로는 값 타입만 내보낸다
actor UserService {
    private let legacy = LegacyUserAPI()

    func currentUser() async -> User {
        let raw = await legacy.fetch()   // 여기까지만 레거시 타입
        return User(raw)                 // 밖으로는 Sendable 값만
    }
}

final class LegacyUserAPI {
    func fetch() async -> LegacyUser { LegacyUser() }
}

// ④ 마지막에 strict concurrency를 켜서 남은 구멍을 컴파일 타임에 드러낸다
//    Package.swift:
//      swiftSettings: [.enableUpcomingFeature("StrictConcurrency")]
//    또는 Xcode Build Settings → Strict Concurrency Checking → Complete

let task = Task {
    for item in items {
        try Task.checkCancellation()   // 협력 지점: 취소되면 여기서 throw
        process(item)
    }
}
task.cancel()   // 실행 중인 루프를 멈추지 않는다 — 플래그만 세운다

import Foundation

// cancel()은 플래그만 세운다. 코드가 확인하지 않으면 끝까지 돈다.

// ❌ 취소를 확인하지 않는 루프 — cancel 후에도 100만 번을 다 돈다
func processBad(_ items: [Item]) -> [Result] {
    items.map(transform)
}

// ✅ ① throw 방식 — 취소되면 CancellationError로 즉시 빠져나온다
func process(_ items: [Item]) async throws -> [Result] {
    var out: [Result] = []
    out.reserveCapacity(items.count)
    for item in items {
        try Task.checkCancellation()
        out.append(transform(item))
    }
    return out
}

// ✅ ② 부분 결과를 살려야 하면 플래그로 확인하고 정상 반환
func processPartial(_ items: [Item]) async -> (done: [Result], cancelled: Bool) {
    var out: [Result] = []
    for item in items {
        if Task.isCancelled { return (out, true) }   // 여기까지의 결과를 돌려준다
        out.append(transform(item))
    }
    return (out, false)
}

// ✅ ③ 촘촘한 루프라면 매 반복이 아니라 주기적으로 — 검사도 공짜는 아니다
func processChunked(_ items: [Item]) async throws -> [Result] {
    var out: [Result] = []
    for (i, item) in items.enumerated() {
        if i % 256 == 0 { try Task.checkCancellation() }
        out.append(transform(item))
    }
    return out
}

// ⚠️ 취소를 인지하는 API(Task.sleep, URLSession async)만 쓰는 코드라면
//    별도 확인 없이도 자동으로 멈춘다. 직접 도는 CPU 루프가 문제다.

struct Item {}; struct Result {}
func transform(_ i: Item) -> Result { Result() }

import Foundation

// 취소는 "그만두라"는 신호일 뿐, 열어 둔 자원을 대신 닫아 주지 않는다.

final class Transfer {
    func start(_ url: URL) -> Handle { Handle() }
    final class Handle {
        func result() async throws -> Data { Data() }
        func abort() {}
    }
}

// ✅ 취소 순간 즉시 정리한다
func download(_ url: URL) async throws -> Data {
    let handle = Transfer().start(url)
    return try await withTaskCancellationHandler {
        try await handle.result()
    } onCancel: {
        handle.abort()               // ⚠️ 이 클로저는 취소 스레드에서 즉시 실행된다
        // ⚠️ onCancel 핸들러는 @Sendable이라, 여기서 만지는 타입(Transfer.Handle)도
        //    Sendable이어야 한다. 아니면 Swift 6에서 컴파일 에러다.
    }
}

// ⚠️ onCancel 클로저 안에서는 await를 쓸 수 없고, 동기적으로 짧게 끝내야 한다.
//    비동기 정리가 필요하면 플래그만 세우고 본체에서 처리한다.
actor Uploader {
    private var shouldAbort = false

    func upload(_ data: Data) async throws {
        try await withTaskCancellationHandler {
            try await send(data)
            if shouldAbort { try await rollback() }   // ✅ 비동기 정리는 본체에서
        } onCancel: {
            Task { await self.setAbort() }
        }
    }
    private func setAbort() { shouldAbort = true }
    private func send(_ d: Data) async throws {}
    private func rollback() async throws {}
}

// ✅ 파일·트랜잭션은 defer와 조합하면 경로가 하나로 모인다
func writeWithCleanup(_ url: URL) async throws {
    let tmp = url.appendingPathExtension("tmp")
    defer { try? FileManager.default.removeItem(at: tmp) }   // 정상·취소·에러 모두 커버
    try await writeChunks(to: tmp)
    _ = try FileManager.default.replaceItemAt(url, withItemAt: tmp)
}
func writeChunks(to url: URL) async throws {}

import Foundation
import UIKit

// 사용자가 스스로 취소했는데 "오류가 발생했습니다" 토스트가 뜨면 버그처럼 보인다.

@MainActor
final class SearchViewModel {
    private var task: Task<Void, Never>?

    func search(_ query: String) {
        task?.cancel()                          // 이전 검색 취소
        task = Task {
            do {
                let results = try await api.search(query)
                self.show(results)
            } catch is CancellationError {
                // ✅ 조용히 종료 — 사용자 의도이므로 아무것도 표시하지 않는다
                return
            } catch let error as URLError where error.code == .cancelled {
                // ✅ URLSession은 CancellationError가 아니라 이 코드를 던진다(-999)
                return
            } catch {
                self.showError(error)           // ✅ 진짜 실패만 노출
            }
        }
    }

    private func show(_ r: [String]) {}
    private func showError(_ e: Error) {}
}

// ⚠️ API마다 취소를 알리는 에러 타입이 다르다 — 헬퍼로 한곳에 모아 둔다
extension Error {
    var isCancellation: Bool {
        self is CancellationError
            || (self as? URLError)?.code == .cancelled
            || (self as NSError).code == NSUserCancelledError
    }
}

func handle(_ error: Error) {
    guard !error.isCancellation else { return }
    // 실제 오류 처리
}

enum api { static func search(_ q: String) async throws -> [String] { [] } }

import Foundation

// 구조적 동시성에서는 부모가 취소되면 자식도 취소된다. detached는 그 사슬을 끊는다.

@MainActor
final class Screen {
    private var work: Task<Void, Never>?

    // ✅ Task { } — 부모 취소가 전파된다
    func startStructured() {
        work = Task {
            await longRunningWork()          // cancel() 하면 내부 await가 취소된다
        }
    }

    // ❌ 부모 Task 안에서 detached를 띄우면 부모 취소가 전파되지 않는다
    func startDetached() {
        work = Task {                        // 이 Task를 cancel해도…
            Task.detached { await longRunningWork() }   // …이 안쪽은 계속 돈다
            await longRunningWork()
        }
    }
    // ⚠️ 반대로 detached Task의 '핸들'을 직접 들고 cancel()하면 detached도 정상 취소된다.
    //    끊기는 건 부모→자식 자동 전파이지 핸들 취소가 아니다.

    func close() { work?.cancel() }
}

// detached를 꼭 써야 한다면 취소를 직접 배선한다
final class Coordinator {
    private var handle: Task<Void, Never>?

    func start() {
        let task = Task.detached { await longRunningWork() }
        handle = task
    }
    func stop() { handle?.cancel() }         // ✅ 직접 붙들고 직접 취소
}

/*  팀 규칙으로 명시할 것:
      · 기본은 Task { } / async let / TaskGroup
      · Task.detached는 "호출자 수명과 무관하게 끝까지 가야 하는 작업"에만
      · detached를 쓰면 취소·우선순위·actor 격리·task-local이 모두 끊긴다는 점을
        코드 리뷰 체크리스트에 넣는다                                          */

func longRunningWork() async {}