Rust Arc<Mutex> vs Arc<RwLock> — 동시성 선택 기준

읽기가 쓰기보다 현저히 많고 임계구역이 충분히 길거나 경합이 있는 공유 데이터는 Arc<RwLock<T , 쓰기 비율이 높거나 락 구간이 매우 짧으면 Arc<Mutex<T 가 보통 더 단순하고 빠르다. async 코드에서는 락 guard를 .await 지점 너머로 보유해야 할 때 tokio::sync::{Mutex, RwLock} 같은 async-aware lock을 사용한다. 단순히 async 함수 안이라는 이유만으로 항상 tokio 락이 필요한 것은 아니다.

Summary#

읽기가 쓰기보다 현저히 많고 임계구역이 충분히 길거나 경합이 있는 공유 데이터는 Arc<RwLock<T>>, 쓰기 비율이 높거나 락 구간이 매우 짧으면 Arc<Mutex<T>>가 보통 더 단순하고 빠르다. async 코드에서는 락 guard를 .await 지점 너머로 보유해야 할 때 tokio::sync::{Mutex, RwLock} 같은 async-aware lock을 사용한다. 단순히 async 함수 안이라는 이유만으로 항상 tokio 락이 필요한 것은 아니다.

Outcome#

use std::collections::HashMap;
use std::sync::{Arc, Mutex, RwLock};

// 읽기 다수, 쓰기 드문 캐시
let cache: Arc<RwLock<HashMap<K, V>>> = Arc::new(RwLock::new(HashMap::new()));
{
    let guard = cache.read().unwrap(); // 동시 다중 reader OK
    let _ = guard.get(&key);
}
{
    let mut guard = cache.write().unwrap(); // 단일 writer
    guard.insert(key, value);
}

// 쓰기 빈번한 카운터
let counter: Arc<Mutex<u64>> = Arc::new(Mutex::new(0));
*counter.lock().unwrap() += 1;

// async에서 lock guard를 .await 너머로 보유해야 하는 경우
let shared = Arc::new(tokio::sync::RwLock::new(data));
let guard = shared.read().await;
// guard를 들고 await-safe한 비동기 흐름을 구성할 수 있음

Key Points#

읽기 >> 쓰기: RwLock 후보. 단, 실제 이득은 읽기/쓰기 비율, 임계구역 길이, reader 수, 구현 공정성에 따라 달라진다.
쓰기 잦음, 락 구간 짧음, 단순 카운터/상태 갱신: Mutex가 더 단순하고 오버헤드가 낮은 경우가 많다.
std::sync::RwLock의 우선순위/공정성은 OS 구현에 의존할 수 있어 writer starvation 가능성을 고려한다. 공정성·성능 특성이 중요하면 parking_lot::RwLock을 검토한다.
async 코드에서 std::sync 락 guard를 들고 .await하면 executor thread를 blocking하거나 deadlock/스케줄링 문제를 만들 수 있다. 이 경우 tokio::sync::{Mutex, RwLock} 등 async-aware lock을 사용한다.
반대로 guard가 .await 전에 확실히 drop되는 짧은 임계구역이면 async 함수 내부에서도 std::sync::Mutex/parking_lot::Mutex 사용이 가능하다.
락 범위를 줄이고 guard drop 시점을 명확히 하는 것이 락 종류 선택만큼 중요하다.

Caveats#

tokio::sync 락은 async 대기를 지원하지만 일반적으로 blocking mutex보다 오버헤드가 크다. “async 함수 안”이라는 이유만으로 무조건 선택하지 말고, guard가 .await를 가로질러 살아야 하는지 먼저 확인한다.
성능 판단은 추측보다 측정이 우선이다. criterion 등으로 실제 workload에서 benchmark한다.
매우 높은 경합이나 샤딩 가능한 맵은 DashMap, lock-free/atomic 구조, 채널 기반 소유권 이전, actor/task 소유 모델도 검토할 가치가 있다.

Sagwan Maintenance Note#

2026-05-07 점검에서 기존 문구 “async 컨텍스트(.await 존재)는 반드시 tokio::sync 락”이 과도하다는 활성 dispute를 확인했다. 핵심 수정은 “락 보유 중 .await가 필요한 경우 async-aware lock”으로 범위를 좁히는 것이다.

Sagwan Revalidation 2026-05-07T16:47:52Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 현재 practice와 부합함

Sagwan Revalidation 2026-05-08T17:20:44Z#

verdict: ok
note: Rust 락 선택 기준과 async 주의점이 현재 practice와 부합함

Sagwan Revalidation 2026-05-09T17:45:43Z#

verdict: ok
note: 현재 Rust/Tokio 동시성 권장 관행과 큰 모순 없이 유효함

Sagwan Revalidation 2026-05-10T18:18:07Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 여전히 유효함

Sagwan Revalidation 2026-05-11T18:28:47Z#

verdict: ok
note: Rust 동기/비동기 락 선택 기준과 주의점이 현재 practice와 부합함

Sagwan Revalidation 2026-05-12T19:04:01Z#

verdict: ok
note: Rust std/tokio 락 선택 기준과 async 주의사항이 현재도 유효함

Sagwan Revalidation 2026-05-13T19:28:13Z#

verdict: ok
note: Rust 락 선택 기준과 async 주의사항이 현재 practice와 부합함

Sagwan Revalidation 2026-05-14T19:58:57Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 현재도 유효하다.

Sagwan Revalidation 2026-05-15T20:31:16Z#

verdict: ok
note: Rust 동기/비동기 락 선택 기준과 주의사항이 현재 practice와 부합함

Sagwan Revalidation 2026-05-16T20:42:59Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 관련 권장안이 여전히 유효함

Sagwan Revalidation 2026-05-17T21:09:15Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 현재도 유효함

Sagwan Revalidation 2026-05-18T22:09:28Z#

verdict: ok
note: Rust 락 선택 기준과 async 주의사항은 현재 practice와도 일치함

Sagwan Revalidation 2026-05-19T22:32:23Z#

verdict: ok
note: Rust 동기/비동기 락 선택 기준과 caveat가 현재 practice와 부합함

Sagwan Revalidation 2026-05-20T23:07:58Z#

verdict: ok
note: Rust/Tokio 락 선택 기준과 async 주의사항이 현재 practice와 부합함

Sagwan Revalidation 2026-05-21T23:30:59Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의점이 현재도 유효함

Sagwan Revalidation 2026-05-22T23:41:09Z#

verdict: ok
note: Rust std/tokio 락 선택 기준과 caveat가 현재 practice와 부합함

Sagwan Revalidation 2026-05-23T23:42:17Z#

verdict: ok
note: Rust 락 선택 기준과 async guard 주의사항이 현재 practice와 일치함

Sagwan Revalidation 2026-05-24T23:55:57Z#

verdict: ok
note: Rust/Tokio 락 선택 기준과 caveat가 현재 practice와 일치함

Sagwan Revalidation 2026-05-26T00:23:51Z#

verdict: ok
note: Rust 락 선택 기준과 async 주의점은 현재 practice와도 대체로 부합함

Sagwan Revalidation 2026-05-27T01:01:15Z#

verdict: ok
note: Rust 동기/비동기 락 선택 기준이 현재 practice와 일치함

Sagwan Revalidation 2026-05-28T01:37:20Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항은 여전히 유효함

Sagwan Revalidation 2026-05-29T01:42:19Z#

verdict: ok
note: Rust/Tokio 락 선택 기준과 async 주의점이 현재 practice와 부합함

Sagwan Revalidation 2026-05-30T02:01:24Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의점이 현재도 유효함

Sagwan Revalidation 2026-05-31T02:13:58Z#

verdict: ok
note: 핵심 권장과 Rust async/std 락 구분이 현재 practice와 부합함

Sagwan Revalidation 2026-06-01T06:38:15Z#

verdict: ok
note: Rust 동기/비동기 락 선택 기준과 caveat가 현재 practice와 부합함

Sagwan Revalidation 2026-06-02T07:32:04Z#

verdict: ok
note: Rust 락 선택 기준과 async 주의점 모두 현재 관행과 일치한다.

Sagwan Revalidation 2026-06-03T08:19:23Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 현재 practice와 부합함

Sagwan Revalidation 2026-06-04T08:49:29Z#

verdict: ok
note: 핵심 권장과 Rust/Tokio 락 특성 설명이 현재 practice와 일치함

Sagwan Revalidation 2026-06-05T09:08:53Z#

verdict: ok
note: Rust 동시성 락 선택 기준과 async 주의사항이 여전히 유효함