4. Java 동시성 기초

i++가 왜 Thread-safe하지 않은지, volatile과 synchronized의 차이가 무엇인지 정확히 설명할 수 있어야 합니다. 이 챕터는 CPU 캐시 수준의 원인부터 Java가 제공하는 세 가지 해결책 (volatile / synchronized / Atomic)까지 계층적으로 설명합니다.

1. 근본 원인 — CPU 캐시와 메모리 가시성

현대 CPU는 Main Memory(RAM)에서 데이터를 직접 읽지 않습니다. 속도 차이가 너무 크기 때문에(CPU: ns급 vs RAM: 60~100ns) 레지스터 → L1 → L2 캐시에 데이터를 복사해 두고 작업합니다. 이것이 동시성 문제의 근원입니다.

Thread-A가 x = 1을 쓰고 Main Memory에 반영했더라도, Thread-B의 CPU 캐시에는 아직 x = 0이 남아 있을 수 있습니다. 이것이 가시성(Visibility) 문제입니다.

세 가지 동시성 문제가 있습니다:

2. volatile — 가시성 보장 (단, 원자성은 아님)

volatile 키워드가 붙은 변수는 항상 Main Memory에서 읽고 씁니다. CPU 캐시를 거치지 않으므로 가시성 문제가 해결됩니다. 또한 메모리 배리어(Memory Barrier)를 삽입해서 명령어 재정렬도 방지합니다.

class StopTask {
    // 캐시에서 읽을 수 있음
    private boolean running = true;

    public void stop() {
        running = false; // Thread-A가 씀
    }

    public void run() {
        // Thread-B가 캐시에서 읽으면
        // running=true인 채로 무한루프!
        while (running) {
            doWork();
        }
    }
}

class StopTask {
    // 항상 Main Memory에서 읽고 씀
    private volatile boolean running = true;

    public void stop() {
        running = false; // Main Memory에 즉시 반영
    }

    public void run() {
        // 항상 최신 값을 읽음
        while (running) {
            doWork();
        }
    }
}

3. synchronized — 원자성 + 가시성 + 순서 모두 보장

synchronized는 모니터 락(Monitor Lock)을 통해 한 번에 하나의 스레드만 임계 구역에 진입하도록 보장합니다. 락 해제 시 모든 변경사항이 Main Memory에 반영되므로 가시성도 함께 보장됩니다.

public class Counter {
    private int count = 0;

    // 메서드 전체에 this 객체 락
    public synchronized void increment() {
        count++;
    }

    public synchronized int get() {
        return count;
    }
}
// 단점: 메서드 전체가 임계 구역
//        → 락 경합 범위가 넓어짐

public class OrderService {
    private final Object lock = new Object();
    private int pending = 0;

    public void placeOrder(Order order) {
        validateOrder(order); // 락 불필요

        synchronized (lock) { // 임계 구역만 보호
            pending++;
            process(order);
            pending--;
        }

        notify(order); // 락 불필요
    }
}
// 락 보유 시간을 최소화 → 성능 향상

4. happens-before — "이 작업은 저 작업 이전에 반드시 완료된다"

JMM(Java Memory Model)은 happens-before 관계를 정의합니다. A happens-before B라면, A의 모든 결과가 B에게 가시적으로 보장됩니다.

// 공유 변수 (volatile 없음)
int data = 0;
boolean ready = false;

// Thread-A
data = 42;
ready = true; // 재정렬 가능!

// Thread-B
if (ready) {
    // data가 0일 수도 있음
    // ready 쓰기가 data 쓰기보다
    // 먼저 보일 수 있기 때문
    System.out.println(data);
}

int data = 0;
volatile boolean ready = false;

// Thread-A
data = 42;
// volatile 쓰기 → 이전 작업 모두 완료 후
ready = true;

// Thread-B
if (ready) { // volatile 읽기
    // ready=true라면 data=42가 반드시 보임
    // volatile 읽기 HB 관계로 보장
    System.out.println(data); // 반드시 42
}

5. Atomic 클래스 — Lock-free 원자적 연산

synchronized는 락 경합(contention) 시 컨텍스트 스위칭이 발생해 성능이 저하됩니다. Atomic 클래스는 CPU 수준의 CAS(Compare-And-Swap) 인스트럭션을 사용해 락 없이 원자적 연산을 구현합니다.

public class SyncCounter {
    private int count = 0;

    public synchronized void increment() {
        count++; // 락 획득 → 해제 반복
        // 스레드 많을수록 컨텍스트 스위칭 폭발
    }

    public synchronized int get() {
        return count;
    }
}

public class AtomicCounter {
    // CAS 기반, 락 없음
    private AtomicInteger count
        = new AtomicInteger(0);

    public void increment() {
        count.incrementAndGet(); // CAS 원자적 연산
    }

    public int get() {
        return count.get();
    }
}
// 고경합 환경에서 synchronized보다 빠름

// 설정 객체를 무중단 교체 시
AtomicReference<Config> config =
    new AtomicReference<>(initialConfig);

// Thread-safe하게 새 설정으로 교체
Config old = config.get();
Config updated = buildNewConfig(old);
// CAS: old와 현재 값이 같을 때만 updated로 교체
boolean success = config.compareAndSet(
    old, updated
);

// ABA 문제: A→B→A 변경 후 CAS가 성공해버림
// stamp(버전)을 함께 관리해서 방지
AtomicStampedReference<Node> ref =
    new AtomicStampedReference<>(node, 0);

int[] stamp = new int[1];
Node current = ref.get(stamp); // stamp[0]=현재 버전

// 버전도 일치해야 교체 성공
ref.compareAndSet(
    current, newNode,
    stamp[0], stamp[0] + 1
);

6. 실무 동기화 도구 선택 가이드

7. 면접 대비 핵심 Q&A