Go map을 여러 고루틴이 읽고 일부가 갱신합니다. 키가 다르면 잠금 없이 사용해도 되나요?

일반 map의 동시 읽기와 쓰기는 키가 다르더라도 안전하다고 가정할 수 없습니다. 내부 구조 변경과 공유 메모리 접근이 있으므로 mutex·소유 고루틴·불변 snapshot 같은 동기화가 필요합니다.

동작 원리와 전제

읽기 전용으로 완성한 map을 안전하게 공개하고 이후 변경하지 않으면 공유할 수 있습니다. map 안의 포인터가 가리키는 객체가 가변이면 그 객체의 동시성도 별도입니다. sync.Map은 특정 접근 패턴에 유용하지만 여러 연산의 복합 불변식을 자동 보호하지 않습니다.

선택과 실패 처리

Load 후 조건을 보고 Store하는 흐름은 각각 안전해도 전체는 경쟁할 수 있습니다. LoadOrStore·CompareAndSwap 등 지원 원자 동작이나 락 범위를 사용합니다. 전체 순회 snapshot이 필요한지와 Range의 계약을 구분합니다.

구체적인 사례와 검증

서로 다른 키에 쓰는 두 요청도 bucket 확장이나 내부 메타데이터를 공유할 수 있습니다. 각자 키가 다르다는 논리 조건만으로 자료구조 내부 경쟁을 배제할 수 없는 이유입니다. 한 owner 고루틴이 명령을 받아 map을 수정하면 원자 범위를 표현하기 쉽지만 큐 대기와 owner의 처리 상한이 생깁니다. RWMutex를 사용할 때도 읽기 락 안에서 value 객체를 바꾸면 보호 의미가 어긋납니다. 불변 map을 새로 만들어 루트를 교체하는 방법은 읽기를 단순화하지만 복사·이전 버전 보관 비용을 만듭니다. 실제 읽기·쓰기 비율과 map 크기에 맞춰 선택하고 개별 API 이름만으로 모든 복합 연산을 안전하다고 보지 않습니다.

race detector와 동시 갱신·삭제·복합 연산 테스트를 함께 사용합니다. fatal 오류가 안 났다는 사실은 안전성 증명이 아닙니다. 키 샤딩으로 경합을 줄일 때도 여러 샤드에 걸친 원자성과 잠금 순서를 설계해야 합니다.