Concurrency Lock Race Condition
3줄 요약
- Concurrency 문제는 여러 thread가 같은 상태를 동시에 읽고 쓰면서 순서와 가시성이 깨질 때 발생한다.
- Lock은 critical section을 보호하지만 deadlock, starvation, contention, throughput 저하를 만들 수 있다.
- Thread-safe 설계는 synchronized나 Atomic 사용 여부가 아니라 공유 상태를 줄이고 불변성과 경계를 명확히 하는 문제다.
핵심 정리
- Race condition은 실행 순서에 따라 결과가 달라지는 버그다.
- Critical section은 동시에 실행되면 안 되는 공유 상태 변경 구간이다.
synchronized, Lock, ReentrantLock은 mutual exclusion과 memory visibility를 다루는 도구다.volatile, Atomic*, concurrent collection은 목적이 다르므로 단순히 빠른 lock 대체재로 보면 안 된다.- Thread-safe 판단은 상태 소유권, 불변 객체, transaction 경계, DB lock, application lock을 함께 본다.
헷갈리는 지점
- 테스트에서 통과하면 동시성 문제가 없다고 보기 쉽다.
- Race condition은 timing에 의존해 재현이 낮을 수 있다.
- 부하, 반복, thread dump, 코드 구조로 위험을 판단해야 한다.
- volatile이 모든 동시성 문제를 해결한다고 오해하기 쉽다.
- volatile은 가시성과 일부 순서 보장을 제공하지만 복합 연산의 원자성을 보장하지 않는다.
- 카운터 증가 같은 작업은 Atomic이나 lock이 필요할 수 있다.
- Lock을 많이 걸면 안전하다고 생각하기 쉽다.
- Lock 범위가 넓으면 처리량이 떨어지고 deadlock 위험이 커진다.
- 공유 상태를 줄이는 설계가 우선이다.
확인 질문
- Race condition은 무엇인가?
- 여러 실행 흐름의 순서에 따라 결과가 달라지는 버그다.
- Deadlock을 의심할 때 가장 먼저 볼 증거는 무엇인가?
- Thread dump에서 서로 다른 thread가 상대 lock을 기다리는 구조와 BLOCKED 상태다.
- Thread-safe 설계의 첫 단계는 무엇인가?
- 공유 상태를 줄이고 상태의 소유자와 변경 경계를 명확히 하는 것이다.