질문의 역사 질문은 스위프트가 Objective-C의 수동 메모리 관리 및 변경 가능한 클래스 계층에서 현대의 값 유형 중심 패러다임으로 전환하는 과정에서 나타났습니다. 초기 스위프트 버전은 **Copy-on-Write (CoW)**를 최적화로 도입하여 배열 및 사전과 같은 값 유형이 변이가 발생할 때까지 기본 저장소를 공유하게 했습니다. 그러나 개발자들은 초기에는 값 의미론이 자동 스레드 안전성을 의미한다고 오해하여 동시 코드에서 미세한 경쟁 조건이 발생했습니다. 이 오해는 **Grand Central Dispatch (GCD)**와 이후 Swift Concurrency의 채택과 함께 문제가 심각해졌으며, 값 유형 내의 공유 변경 가능한 상태가 예측할 수 없는 충돌을 일으켜 재현하기 어려운 상황이 발생했습니다.
문제
배열은 언어 수준에서 값 유형으로 동작하지만, 내부 구현은 요소를 저장하기 위해 참조 카운트된 힙 버퍼를 사용합니다. 여러 스레드가 동일한 배열 인스턴스에 동시에 접근할 경우—심지어 append와 같은 안전해 보이는 작업을 수행하더라도—CoW 메커니즘이 활성화됩니다. 고유성을 확인하는 체크(isKnownUniquelyReferenced) 및 이후의 버퍼 변경은 별도의 비원자적 작업입니다. 이는 두 스레드가 동시에 버퍼가 비고유하다고 결정하고 동시에 복사하거나, 더 나쁜 경우 올바른 동기화 없이 공유 버퍼를 수정할 수 있는 경쟁 창을 생성합니다. 이는 메모리 손상, 참조 카운트 불균형, 또는 EXC_BAD_ACCESS 충돌을 초래합니다.
해결책 스위프트는 프로그래머에게 스레드 경계를 넘는 값 유형에 대한 격리 경계를 적용하도록 의존합니다. 언어는 Swift 5.5에서 도입된 actor를 기본 메커니즘으로 제공하여 변경 가능한 상태가 Sendable 프로토콜을 준수함으로써 직렬로 접근되도록 보장합니다. Alternatively, 전통적인 동기화 원시 객체인 NSLock 또는 직렬 DispatchQueue 장벽을 통해 배열 변경을 캡슐화할 수 있습니다. 중요하게도, 스위프트 6는 엄격한 동시성 체크를 통해 컴파일 타임 데이터 경쟁 감지를 수행하여, 동시성 도메인 간의 변경 가능한 값 유형의 암묵적 공유를 런타임 실패가 아닌 컴파일 오류로 만듭니다.
// 안전하지 않은 동시 접근 var sharedArray = [1, 2, 3] DispatchQueue.concurrentPerform(iterations: 100) { _ in sharedArray.append(Int.random(in: 0...100)) // 데이터 경쟁! } // Actor를 사용한 안전한 해결책 actor SafeArray { private var storage: [Int] = [] func append(_ element: Int) { storage.append(element) } func getAll() -> [Int] { return storage } } let safeArray = SafeArray() Task { await safeArray.append(42) }
고속 이미지 처리 파이프라인에서는 여러 동시 필터 작업에서 메타데이터 태그를 중앙 리포지토리에 축적해야 했습니다. 각 DispatchQueue 작업자는 변경 가능한 상태가 데이터 경쟁에 대한 원자성 보장을 본질적으로 제공한다고 잘못 가정하여 공유 배열에 구조체 결과를 추가하고 있었습니다. 이 가정은 Copy-on-Write 메커니즘이 버퍼 재할당 중 경합 조건에 직면했을 때, 내부 참조 카운트와 저장 포인터를 손상시켜 간헐적인 EXC_BAD_ACCESS 충격을 유발했습니다.
부하가 심할 때 간헐적 충돌을 해결하기 위해 세 가지 접근 방식을 고려했습니다. 첫 번째로, NSLock이 있는 클래스로 배열을 감싸서 중요한 섹션에 대한 세밀한 제어를 제공했지만, 예외 안전성과 잠금을 유지하는 동안 콜백이 트리거될 경우 잠재적 교착 상태와 관련하여 상당한 복잡성을 도입했습니다. 이 접근법은 또한 여러 공유 리소스에 걸쳐 잠금 계층 구조를 수동으로 관리해야 하여 유지 관리 중 인적 오류의 위험을 증가시켰습니다.
두 번째로, 동기화 메커니즘으로 직렬 DispatchQueue를 사용하여 queue.sync를 통한 쓰기 및 queue.async를 통한 읽기를 활용하여 FIFO 순서를 보장하는 방법을 테스트했습니다. 이로써 데이터 경합이 제거되었지만 모든 작업이 직렬화되어 동시에 수천 개의 이미지를 처리할 때 심각한 병목 현상이 발생했습니다. 대기열 경합은 최대 부하 중 처리량을 약 40% 감소시켜 병렬 처리의 이점을 실질적으로 상쇄했습니다.
세 번째로, MetadataStore라는 사용자 정의 Actor를 구현하여 배열을 격리하고 변경을 위한 비동기 메서드만 노출시켜, 스위프트의 구조적 동시성 모델을 활용했습니다. 이러한 접근 방식은 모든 상태 접근이 actor의 직렬 실행자에서 발생하도록 보장해 데이터 경합을 구성이 아닌 수동 동기화 원시 객체를 통해 방지했습니다. 컴파일러는 이러한 보장을 Sendable 프로토콜을 사용하여 강제합니다.
우리는 Actor 접근 방식을 선택했습니다. 이는 스위프트의 정적 동시성 분석을 통해 컴파일 타임 데이터 경합 안전성을 제공했기 때문입니다. 이는 더 낮은 수준의 원시 객체와 관련된 수동 잠금 관리 오버헤드를 제거했습니다. 마이그레이션은 동기 콜백을 비동기/대기 패턴으로 리팩토링할 필요가 있었지만, 결과적으로 생산 환경에서 충돌 비율이 0%로 감소하고 잠금 접근 방법에 비해 성능이 15% 향상되었습니다.
왜 isKnownUniquelyReferenced가 다른 참조가 존재하지 않을 때에도 예상치 못하게 false를 반환하나요?
이것은 컴파일러가 스위프트 유형을 Objective-C로 연결하거나 디버그 빌드 중에 샌타이저가 활성화될 때 임시 참조를 생성할 수 있기 때문입니다. 또한 값이 클로저에 캡처되거나 inout 매개변수를 받는 함수에 전달되면, 컴파일러는 참조 카운트를 증가시키는 그림자 복사본을 삽입합니다. 후보자들은 종종 고유성이 정적 분석이 아닌 런타임 참조 카운트에 의해 결정된다는 점과 최적화 수준(-O, -Onone)이 이 동작에 중대한 영향을 미친다는 사실을 간과합니다.
Copy-on-Write가 대규모 데이터 변환 성능에 미치는 영향은 무엇인가요?
많은 사람들은 CoW가 불변 지속 데이터 구조와 동일한 복잡성 보장을 제공한다고 가정합니다. 그러나 스위프트의 CoW는 공유 이후 첫 번째 변형에서 O(n) 복사를 발생시킬 수 있으며, 이로 인해 알고리즘의 중간 단계에서 지연이 발생할 수 있습니다. 후보자들은 종종 withUnsafeMutableBufferPointer 또는 inout 매개변수를 사용하여 이 중간 복사를 방지할 수 있음을 간과하거나 ContiguousArray를 사용하여 클래스 요소가 아닌 요소에 대한 참조 카운트 오버헤드를 제거할 수 있습니다.
스위프트의 다가오는 ~Copyable 및 ~Escapable 제약 조건의 맥락에서 스레드 안전한 값 의미론과 스레드 안전한 참조 유형의 차이는 무엇인가요?
스위프트 6에서 비복사 가능한 유형이 도입되면서, 값 유형이 이제 고유 소유권을 강제할 수 있습니다(~Copyable). 이는 CoW가 불가능한 진정한 선형 유형을 제공하고, 후보자들은 종종 이로 인해 동시성 모델이 "CoW로 공유"에서 "이동전용 고유성"으로 변경되며, 여기서 스레드 안전성은 동기화를 넘어서 독점성에 의해 보장된다는 사실을 간과합니다. borrowing 및 consuming 매개변수 수정자가 값을 동시성 경계를 넘는 방식에 변화를 일으킨다는 점은 향후 스위프트 개발에 있어 중요합니다.