[Java] volatile - 멀티스레드 가시성 문제 트러블슈팅

들어가며

 독립 큐 + 전용 워커 스레드를 사용하는 서비스에서 종료 신호가 워커 스레드에 전달되지 않는 문제가 발생했다. @PreDestroy에서 running = false를 분명히 썼는데도 워커 스레드는 루프를 계속 돌고 있었다.

 

private volatile boolean running = true;

 

 해결책은 volatile 한 키워드였지만, 왜 없으면 안 되는지는 설명하기 어려웠다. 이 글은 문제의 원인을 파악하고 올바른 구현에 이르기까지의 과정을 담았다.

 

 

 

 

 

---

1. 문제 발생 - volatile 없이 어떤 일이 벌어지는가

 volatile 없이 종료 플래그를 구현하면 어떤 일이 생기는지 코드로 먼저 보자.

// volatile 없음
private boolean running = true;

// 워커 스레드 (Core 1에서 실행)
private void runWorker(String id, BlockingQueue<Runnable> queue) {
    while (running) {  // ← Core 1의 캐시에서 running 읽기
        Runnable task = queue.poll(500, TimeUnit.MILLISECONDS);
        if (task == null) continue;
        task.run();
        Thread.sleep(1000);
    }
    drainQueue(id, queue);
}

// 메인 스레드 (Core 0에서 실행)
@PreDestroy
public void shutdown() {
    running = false;  // ← Core 0의 캐시를 false로 변경
    // 메인 메모리에 언제 반영될지 보장 없음
}

 

 shutdown()이 running = false를 썼음에도 워커 스레드가 루프를 빠져나오지 않는다.

 

 

 

 

 

---

2. 원인 분석 - CPU 캐시와 메모리 가시성

 현대 CPU는 메인 메모리(RAM)에 직접 접근하는 대신 L1/L2/L3 캐시를 계층적으로 사용한다. 메인 메모리 접근은 수백 클럭이 걸리지만 L1 캐시는 수 클럭이면 충분하기 때문이다.

 

 

 

 Java Memory Model(JMM) 은 성능을 위해 각 스레드가 변수의 로컬 복사본(CPU 캐시 또는 레지스터)을 사용하도록 허용한다. 따라서 한 스레드가 변수를 변경해도 다른 스레드가 그 변경을 언제 볼지 보장하지 않는다.

 

 이것이 가시성(Visibility) 문제다. shutdown()이 running = false를 써도 변경이 메인 메모리에 즉시 flush되지 않을 수 있고, 설령 flush되더라도 Core 1의 캐시가 갱신되지 않으면 워커 스레드는 영원히 running == true를 보게 된다.

 

 

 

 

---

3. 해결책 - volatile 선언

private volatile boolean running = true;

 

 volatile을 선언하면 JMM은 두 가지를 보장한다.

 

 

 

 

3-1. 가시성 보장 (Visibility)

 volatile 변수에 대한 쓰기는 즉시 메인 메모리에 flush되고, 읽기는 항상 메인 메모리에서 직접 읽는다. CPU 캐시를 우회하므로 모든 스레드가 최신 값을 본다.

 

 

 

 

3-2. 명령어 재정렬 방지 (Happens-Before)

 JMM은 volatile 쓰기와 읽기 사이에 happens-before 관계를 보장한다.

 

 volatile 변수에 대한 쓰기는 이후 같은 변수를 읽는 모든 작업보다 happens-before 한다.

 이 말은 running = false 이전에 수행된 모든 쓰기 작업이 running을 읽는 스레드에도 보장된다는 의미다.

 

 

 

 

 

 

---

4. 올바른 구현 - 백그라운드 워커 스레드 종료

 독립적인 작업 큐와 전용 워커 스레드를 운영하는 구조다.

// volatile 있음
private volatile boolean running = true;  // ← 핵심

// 워커 스레드 (Core 1에서 실행)
private void runWorker(String id, BlockingQueue<Runnable> queue) {
    while (running) {  // ← 메인 메모리에서 매번 읽기
        Runnable task = queue.poll(500, TimeUnit.MILLISECONDS);
        if (task == null) continue;
        task.run();
        Thread.sleep(1000);
    }
    drainQueue(id, queue);  // 잔여 작업 처리
}

// 메인 스레드 (Core 0에서 실행)
@PreDestroy
public void shutdown() {
    running = false;  // ← 메인 메모리에 즉시 반영
    executors.values().forEach(ExecutorService::shutdown);
    // ... awaitTermination
}

 

• 쓰는 스레드: @PreDestroy를 호출하는 메인(Spring 컨텍스트) 스레드
• 읽는 스레드: runWorker()를 실행 중인 워커 스레드들 (id당 1개)

 서로 다른 스레드이므로, volatile 없이는 워커 스레드가 running = false를 영원히 못 볼 수도 있다.

 

 

 

 

 

 

---

5. 주의사항 - volatile이 해결하지 못하는 것

volatile은 가시성과 happens-before를 보장하지만, 복합 연산의 원자성은 보장하지 않는다.

private volatile int count = 0;

// 스레드 A와 B가 동시에
count++;

 

 count++는 실제로 세 단계다: 읽기 → 증가 → 쓰기.

 

 두 스레드가 동시에 읽기 단계를 통과하면 둘 다 같은 값을 읽고, 둘 다 +1을 한 뒤 같은 값을 두 번 쓴다. 결과적으로 증가가 한 번밖에 반영되지 않는다.

 

 

 이런 경우엔 AtomicInteger를 써야 한다.

private final AtomicInteger count = new AtomicInteger(0);
count.incrementAndGet();  // CAS 연산으로 원자성 보장

 

 

 

 

 

---

참고

• Java Language Specification — §17.4 Memory Model
  • CPU 캐시와 가시성 문제 - JMM이 스레드별 로컬 복사본을 허용
  • volatile 의 두 가지 보장 - 가시성(flush/read 보장)과 happens-before 관계