이 설계 결정은 표준 라이브러리 컬렉션에 대한 스위프트의 근본적인 값 의미론에 대한 헌신에서 기인합니다. Objective-C의 NSMutableDictionary나 **C++**의 std::unordered_map와는 달리, 참조 의미론을 드러내거나 내부 노드에 대한 외부 포인터를 허용하지 않는 스위프트는 Dictionary와 Set을 순수한 값 타입으로 취급합니다. 스위프트가 이러한 컬렉션에 대해 값 타입의 안전성을 유지하면서 참조 타입 성능을 달성하기 위해 Copy-on-Write (COW) 최적화를 채택했을 때, 엔지니어링 팀은 인덱스 안정성에 관한 중대한 결정을 내려야 했습니다. 변화를 통한 인덱스 무효화의 해결책은 해시 테이블의 성장, 충돌 해결 또는 항목 삭제 중에 재할당된 저장소에 대한 유령 참조를 방지하기 위해 공식화되었습니다.
핵심 문제는 COW 의미론과 해시 테이블 구현 세부 사항 간의 상호 작용에서 발생합니다. Dictionary가 삽입 또는 삭제를 통해 변경될 때, 로드 팩터가 임계값을 초과하면 리사이즈가 발생하여 새로운 더 큰 버퍼를 할당하고 모든 항목을 다시 해시할 수 있습니다. 변경 이전에 생성된 모든 기존 Index 값은 이전 버퍼의 물리 메모리로의 오프셋이나 포인터를 캡슐화합니다. 만약 변경 이후에 해당 인덱스에 접근한다면, 해제된 메모리(use-after-free)를 역참조하거나 잘못된 버킷의 데이터를 반환하게 됩니다. 스위프트는 독립적인 Dictionary 복사본 간의 모든 Index 값의 생애를 추적할 수 없기 때문에(값 의미론은 무제한 복사를 허용) 모든 미해결 인덱스를 안전하게 업데이트할 수 없습니다. 그러므로 이 언어는 메모리 안전 보장을 유지하기 위해 이러한 인덱스를 무효하다고 선언해야 합니다.
스위프트는 Dictionary의 내부 저장 헤더에 세대 카운트나 버전 번호를 내장하여 이 문제를 해결합니다. 각 Index는 생성 시 이 세대 식별자를 캡처합니다. Dictionary가 변경될 때, 런타임은 이 세대 카운트를 증가시키고 잠재적으로 기본 버퍼를 재할당합니다. 이후에 오래된 Index를 사용하는 것은 저장된 세대를 현재 세대와 비교하게 되며, 불일치가 발생하면 결정론적 런타임 오류(전제 조건 실패)가 발생합니다. 이 접근 방식은 메모리 안전 및 값 의미론 무결성을 위해 변동 과정에서 인덱스 안정성을 희생하는 것입니다. COW 최적화를 위해, 런타임은 변화를 분하기 전에 참조 카운트를 확인합니다: 유일하게 참조되고 있다면, 제자리에서 변경을 수행하여 인덱스를 무효화합니다; 만약 공유되고 있다면, 먼저 버퍼를 복사하여 원래 인스턴스의 인덱스를 유효하게 유지하며 새 복사는 새로운 세대 카운트를 받습니다.
var marketData: [String: Double] = ["AAPL": 150.0, "GOOGL": 2800.0] let indexBeforeUpdate = marketData.index(forKey: "AAPL")! // Generation 0 marketData["TSLA"] = 700.0 // Mutation increments generation, may reallocate // Runtime error: attempting to access using invalid index from generation 0 // let price = marketData[indexBeforeUpdate]
한 개발 팀은 Swift를 사용하여 아이패드에서 고주파 거래 대시보드를 구축하였고, String 티커 기호를 키로 사용하여 라이브 가격 데이터를 캐시하는 Dictionary를 활용하였습니다. 빠른 업데이트 동안 UI 렌더링 성능을 최적화하기 위해 그들은 테이블 뷰 셀 구성을 할 때 반복적인 해시 계산을 피하기 위해 모델 뷰 내에 직접 Dictionary 인덱스를 저장했습니다. 그러나 백그라운드 WebSocket 스레드가 딕셔너리에 새로운 가격 포인트를 삽입할 때, 애플리케이션은 EXC_BAD_ACCESS로 간헐적인 충돌이 발생하거나 해제된 메모리 영역에서 잘못된 데이터가 표시되었습니다. 캐시된 인덱스가 크기 조정 작업 중에 재할당된 해시 테이블의 버킷을 참조했기 때문입니다.
고려된 첫 번째 해결책은 참조 의미론과 안정적인 객체 참조를 제공하는 Foundation의 NSMutableDictionary로 마이그레이션하는 것이었습니다. 이 접근 방식은 팀이 딕셔너리 변경 여부와 관계없이 항목에 대한 영구 참조를 유지할 수 있도록 했습니다. 그러나 이로 인해 참조 의미론이 발생하고 뷰 모델 간 값 유형 분리가 깨져서, 배경 큐와 메인 스레드 간에 딕셔너리를 복사할 때 의도치 않은 데이터 공유와 경쟁 조건이 발생했습니다. 또한, NSMutableDictionary는 스위프트의 제네릭 타입 안전성이 부족하고, 값 타입인 struct 인스턴스의 경우 값으로 브리징하는 데 비싼 오버헤드가 발생하여 성능 저하를 초래했습니다.
두 번째 해결책은 UnsafeMutablePointer를 사용하여 사용자 정의 개방 주소 해시 테이블을 구현하여 안정적인 노드 메모리 주소를 수동으로 관리하려고 하는 것이었습니다. 이를 통해 스위프트의 인덱스 무효화 메커니즘을 완전히 우회할 수 있었습니다. 그러나 이 방법은 삭제 시 적절하게 해제되지 않으면 메모리 누수가 발생할 위험이 상당히 높았고, 해시 테이블의 복잡한 불변 조건을 위반하여 무한 루프나 조용한 데이터 손상, 가능한 경우 후속 Dictionary 작업 중에 충돌할 위험을 초래했습니다. 스위프트의 안전 모델은 이를 명시적으로 금지하며, 안정적인 참조를 유지하는 유일한 안전한 메커니즘은 키를 사용하는 것이거나 컬렉션에서 값으로 별도의 배열에 복사하는 것입니다.
왜 스위프트의 배열은 일부 변동 후 인덱스 재사용을 허용하는 반면, 딕셔너리는 그렇지 않은가? 두 배열 모두 값 타입과 COW 의미론을 가지는데 말이다.
배열 인덱스는 연속 저장에서 기본 주소에 대한 오프셋을 나타내는 가벼운 Int 값입니다. 배열의 재배치(예: 용량 한도를 넘어 추가하는 경우)를 유발하는 변경은 기술적으로 인덱스를 무효화하지만, 배열 인덱스는 검증을 위한 세대 메타데이터를 가지지 않기 때문에 인덱스를 캐시하는 것이 위험하지만 명시적으로 확인되지 않습니다. 그러나 딕셔너리 인덱스는 희소 해시 테이블 내 버킷 오프셋을 포함한 복잡한 내부 상태를 캡슐화합니다. 해시 테이블 항목은 재해시팅 중에 무작위로 이동하므로(로드 팩터 임계값이나 충돌 해결로 인해) 정수 오프셋은 의미를 잃습니다. 스위프트는 이론적으로 딕셔너리에 논리적 인덱스 간접 지정을 구현할 수 있지만, 이렇게 하면 각 접근 속도를 늦추는 추가 포인터 추적이 필요합니다. 따라서 딕셔너리와 집합은 세대 카운트를 통해 인덱스를 공격적으로 검증하고 무효화하는 반면, 배열 인덱스는 프로그래머가 유효성을 보장하도록 의존하며, 이는 연속 저장소와 해시 저장소 간의 성능 및 안전성 트레이드오프를 반영합니다.
COW 메커니즘은 현재 인스턴스에서 딕셔너리 변수가 인덱스를 무효화해야 하는지를 어떻게 결정하는가?
스위프트는 내부 버퍼(_NativeDictionary)에 대해 참조 카운트를 사용합니다. 어떤 변화를 하기 전에 런타임은 isUniquelyReferencedNonObjC를 호출하여 버퍼의 참조 카운트를 확인합니다. 카운트가 1(유일한 소유권)과 같으면, 즉시 변경이 발생하여 인덱스를 무효화하여 세대 수를 증가시킵니다. 만약 참조 카운트가 1을 초과하면(공유된 소유권), 스위프트는 새로운 버퍼를 할당하고 모든 요소를 복사한 후 새 복사본에서 변화를 수행합니다. 원래 인스턴스는 변경되지 않으므로 유효한 인덱스를 가지고 있으며, 새 복사본은 새로운 세대 카운트(실질적으로 인덱스 0)로 시작합니다. 이 차별은 값 의미론에 매우 중요합니다: 값 할당 후 두 변수는 저장소를 공유하다가 하나가 변할 때 지연 복사가 발생합니다. 변동 지점은 논리적 분리가 발생하는 지점으로, 변하는 인스턴스가 변경 전에 고유한 소유권을 갖도록 합니다.
스위프트의 딕셔너리 인덱스 무효화를 withUnsafeMutablePointer 또는 Unmanaged를 사용하여 원시 저장소에 접근하여 우회할 수 있습니까? 그리고 이것이 가져오는 파국적인 위험은 무엇인가요?
기술적으로, UnsafeMutablePointer와 Unmanaged는 withUnsafeMutablePointer를 통해 딕셔너리의 기본 저장소에 직접 접근할 수 있습니다. 그러나 이는 정의되지 않은 동작입니다. 딕셔너리의 내부 레이아웃은 불투명하며 스위프트 버전 간에 변경될 수 있습니다(복원력). 직접 포인터 조작은 세대 수 체크를 우회하여 리사이즈 중에 재할당이 발생했을 때 해제된 메모리에 접근하게 합니다. 또한 해시 테이블은 삭제된 항목에 대한 점유 비트맵 및 흰색 마커와 같은 복잡한 불변 조건을 유지합니다. 수동 포인터 조작은 이러한 불변 조건을 손상시켜 프로브 시퀀스 중 무한 루프, 조용한 데이터 손상 또는 후속 딕셔너리 작업 중 충돌로 이어질 수 있습니다. 스위프트의 안전 모델은 이를 명시적으로 금지하며, 안정적인 참조를 유지하는 유일한 안전한 메커니즘은 키를 사용하는 것(각 접근 시 재해시됨) 또는 컬렉션의 값을 별도의 배열로 복사하는 것입니다.