여러 스레드에서 하나의 객체를 공유 할 때 발생할 수 있는 문제는?

한 문장 요약: "공유 + 가변 + 최소 1개의 쓰기"가 겹치면 데이터가 더럽혀지고(원자성), 변경이 안 보이며(가시성), 순서가 뒤바뀐다(재정렬). 이를 Lock으로 막으면 이번엔 경합·데드락·기아라는 새 문제가 생긴다.

0. 스코핑 경계 (Scoping Boundary)

문제가 성립하는 조건 세 가지가 동시에 만족될 때만 스레드 안전 문제가 발생합니다.

그래서 해결의 1순위는 항상 "셋 중 하나를 없애기"(주로 공유를 줄이거나 불변으로 만들기)입니다. Lock은 셋 다 못 없앨 때의 수단입니다(6장).

이 노트는 JVM 메모리 모델(JMM) 계층을 다룹니다. DB 트랜잭션 격리 수준의 "dirty read"와 용어가 겹치지만 계층이 다릅니다.

1. 데이터가 더럽혀진다 (Corruption) — 가장 눈에 띄는 증상

원인은 공통적으로 "한 번에 끝나야 할 연산이 원자적이지 않다" 입니다.

1.1 갱신 유실 (Lost Update)

class Counter {
    private int count = 0;
    void increment() { count++; }   // 실제로는 read → +1 → write 3단계
}

• 스레드 A와 B가 동시에 count=10을 읽고, 각자 11을 써서 한 번의 증가가 사라짐.
• 10,000번씩 2스레드 → 기대 20,000이지만 실제로는 그보다 작은 값.

1.2 찢어진 상태 (Torn Read) / 불변식 붕괴

class Range {
    private int lower, upper;   // 불변식: lower <= upper
    void set(int l, int u) { this.lower = l; this.upper = u; }  // 두 줄 사이가 노출
}

• A가 set(5, 10) 도중 lower=5만 반영된 순간, B가 읽으면 (5, 이전 upper=3) → 불변식이 깨진 객체를 사용.

1.3 자료구조 자체 파손

• HashMap을 여러 스레드가 동시에 put → 리사이즈(rehash) 중 링크가 꼬여 조회가 무한 루프(Java 7), size가 실제와 불일치, 엔트리 유실.
• ArrayList 동시 add → ArrayIndexOutOfBoundsException 또는 null 슬롯.

1.4 더티 리드 (Dirty Read)

• 롤백될 수도 있는 중간 값을 다른 스레드가 읽어 그대로 사용 → 존재한 적 없는 상태를 기반으로 후속 처리.

2. 변경이 보이지 않는다 (Visibility) — 재현 안 되는 버그의 정체

한 스레드의 쓰기가 다른 스레드에 영원히 반영되지 않을 수 있습니다.

class Worker {
    private boolean running = true;      // 일반 필드
    void run()  { while (running) { /* ... */ } }   // 멈추지 않을 수 있음
    void stop() { running = false; }                 // 다른 스레드가 호출
}

• 원인: CPU 캐시 / 레지스터 상주 / 컴파일러 최적화(호이스팅). running을 매번 메인 메모리에서 읽으리란 보장이 없음.
• volatile boolean running → 읽기/쓰기가 메인 메모리를 거치도록 강제(가시성 확보).
• 주의: volatile은 가시성만 준다. count++ 같은 복합 연산의 원자성은 여전히 미보장.

3. 순서가 뒤바뀐다 (Reordering)

• 컴파일러·CPU·캐시는 단일 스레드 결과가 같기만 하면 명령 순서를 바꿀 수 있습니다.
• 다른 스레드에서 관측하면 코드에 쓴 순서와 실행 관측 순서가 다릅니다.
• 고전 사례 — 이중 검사 잠금(Double-Checked Locking):

if (instance == null) {                 // 1차 검사
    synchronized (lock) {
        if (instance == null)
            instance = new Singleton();  // 객체 참조 대입이 생성자 완료보다 먼저 보일 수 있음
    }
}
return instance;   // 다른 스레드가 "생성 덜 된" 인스턴스를 받을 위험

• 해결: instance를 volatile로 선언(재정렬 차단) 또는 정적 홀더 클래스(Initialization-on-demand holder) 사용.

4. Lock으로 막을 때 생기는 새로운 문제들

동기화는 1~3장을 해결하지만, "락을 걸어서" 생기는 문제가 별도로 존재합니다.

4.1 경합(Contention) — 병렬성이 사라진다

• 임계 구역이 넓으면 스레드들이 락을 기다리며 사실상 직렬 실행.
• 스레드를 늘려도 처리량이 오르지 않음(암달의 법칙: 직렬 구간이 전체 상한을 지배).
• 스레드 덤프에서 BLOCKED 상태 비율로 확인.

4.2 데드락(Deadlock)

// 스레드1: transfer(a, b)  →  lock(a) 후 lock(b) 대기
// 스레드2: transfer(b, a)  →  lock(b) 후 lock(a) 대기  → 서로 영구 대기

• 원인: 락 획득 순서 불일치.
• 해결: 모든 코드가 동일한 순서로 락 획득(예: 계정 ID 오름차순), tryLock(timeout)으로 포기 경로 마련.
• 진단: jstack → Found one Java-level deadlock.

4.3 라이브락 / 기아(Starvation)

• 라이브락: 충돌을 피하려 서로 계속 양보하다 아무도 진행 못 함.
• 기아: 우선순위·불공정 락 때문에 특정 스레드가 락을 계속 못 얻음. ReentrantLock(true)(공정 모드)로 완화(처리량은 하락).

4.4 락 범위 오류

4.5 잘못된 락 객체

• synchronized(this) — 외부에서 이 객체로 락을 걸면 간섭.
• String 리터럴·Integer(−128~127 캐시)로 락 → 의도치 않게 다른 코드와 같은 락 객체 공유.
• 매번 new Object() 를 락으로 → 매번 다른 락 → 보호 실패.
• 권장: private final Object lock = new Object();

4.6 임계 구역 안에서 외부(alien) 메서드 호출

• 락을 쥔 채 콜백·오버라이드 가능 메서드·다른 컴포넌트를 호출하면, 그쪽에서 또 락을 잡아 재진입/데드락.

5. Java 메모리 모델(JMM)이 보장하는 것 / 안 하는 것

동기화 수단은 happens-before 관계를 만들어, "앞의 쓰기가 뒤의 읽기에 보인다"를 보장합니다.

핵심: 동기화(synchronized / volatile / java.util.concurrent)가 하나도 없으면 아무것도 보장되지 않습니다. "지금까지 잘 돌았다"는 우연입니다.

6. 증상 → 원인 매핑표 (진단용)

7. 해결의 우선순위

1. 공유를 없앤다 — 불변 객체(final + 방어적 복사), ThreadLocal, 지역 변수(스택 한정), 스레드 간 전달은 불변 메시지로.
2. 못 없애면 원자 도구 — AtomicInteger/LongAdder(CAS), ConcurrentHashMap, BlockingQueue. 락보다 경합에 강함.
3. 그래도 안 되면 락 — 임계 구역 최소화, 락 획득 순서 전역 고정, tryLock(timeout), ReadWriteLock(읽기 多), 전용 private final 락 객체.