스레드는 왜 서로의 쓰기를 못 볼까? — 메모리 모델의 규칙

"공유 상태를 여러 스레드가 건드린다"는 한 문장 안에 세 가지 독립된 함정이 숨어 있어요. 이 셋을 분리해서 보는 순간, 대부분의 동시성 논의가 명료해집니다.

JMM(Java Memory Model)은 "어떤 스레드의 쓰기가 어떤 스레드의 읽기에 반드시 보여야 하는가"를 규정한 명세예요(JSR-133, Java 5부터 정립). 핵심 도구가 happens-before 관계입니다.

volatile은 두 가지를 보장해요. ① 가시성 — 쓰기는 즉시 메인 메모리에 반영되고 읽기는 항상 최신값을 가져와요. ② 재배치 방지 — volatile write/read 주변으로 메모리 연산이 넘나드는 재배치를 막아요(메모리 배리어).

// ✅ 적합: 단순 플래그 (한 스레드는 쓰기만, 다른 스레드는 읽기만)
volatile boolean running = true;
public void stop() { running = false; }
public void run() { while (running) { /* ... */ } }  // 즉시 중단됨

// ❌ 부적합: 복합 연산엔 원자성이 없다
volatile int count = 0;
count++;   // read → +1 → write 3단계, 경합 시 갱신 유실

synchronized는 객체마다 딸린 모니터 락을 사용해요. 같은 락을 잡아야만 임계 구역에 들어갈 수 있어 상호배제(mutual exclusion)가 되고, 동시에 진입/해제 시점에 happens-before가 성립해 가시성까지 보장됩니다. 즉 원자성·가시성·순서를 한 번에 다뤄요.

class Counter {
    private int count = 0;
    // 메서드 전체 락 — this 모니터를 잡음
    public synchronized void inc() { count++; }   // 원자적 + 가시성 보장

    // 더 좁은 락: 전용 락 객체로 범위 최소화
    private final Object lock = new Object();
    public void incNarrow() {
        // ... 락 없이 할 수 있는 일 ...
        synchronized (lock) { count++; }   // 임계 구역만 감싼다
    }
}

CAS(Compare-And-Swap)는 CPU가 제공하는 원자적 명령이에요. "메모리 위치의 값이 기대값과 같으면 새 값으로 바꾸고, 다르면 실패"를 한 번에 수행합니다. 실패하면 최신값을 다시 읽어 재시도(스핀)해요. 락을 걸지 않으므로 논블로킹(non-blocking)입니다.

AtomicInteger n = new AtomicInteger(0);
int r = n.incrementAndGet();   // 내부적으로 CAS 재시도 루프, 원자적 +1 후 값 반환 → 1
n.compareAndSet(1, 100);       // 현재 값이 1이면 100으로 교체(성공 true)
// count++ 와 달리 경합에서도 갱신 유실이 없다

class Holder {
    // 반드시 volatile! 없으면 부분 초기화된 객체 노출 위험
    private volatile Singleton instance;
    Singleton get() {
        if (instance == null) {              // 1차 검사(락 없이)
            synchronized (this) {
                if (instance == null) {      // 2차 검사(락 안에서)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}