DEV ℧ Developer Diary

[EffectiveJava] item78 - 공유 중인 가변 데이터는 동기화해 사용하라

22 Jul 2023

synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다.

동기화

많은 프로그래머가 동기화를 배타적 실행,즉 한 스레드가 벼경하는 중이라서 상태가 일관되지 않은 순간의 객체를 다른 스레드가 보지 못하게 막는 용도로만 생각한다.

맞는 설명이지만, 동기화에는 중요한 기능이 하나 더 있다. 동기화 없이는 한 스레드가 만든 변화를 다른 스레드에서 확인하지 못할 수 있다.

동기화는 일관성이 깨진 상태를 볼 수 없게 하는것은 물론, 동기화 된 메서드나 블록세 들어간 스레드가 같은 락의 보호하에 수행된 모든 이전 수정의 최종 결과를 보게 해준다.

long, double

long, double 외의 변수를 읽고 쓰는 동작은 원자적(atomic)이다. 여러 스레드가 같은 변수를 동기화 없이 수정하는 중이라도, 항상 어떤 스레드가 정상적으로 저장한 값을 온전히 읽어옴을 보장한다는 뜻이다.

하지만 성능을 높이기 위해 “원자적 데이터를 읽고 쓸 때 동기화하지 말아야 겠다.”라는 생각은 아주 위험한 발상이다.

자바 언어 명세는 스레드가 필드를 읽을 때 항상 ‘수정이 완전히 반영된’ 값을 얻는다고 보장하지만, 한 스레드가 저장한 값이 다른 스레드에게 ‘보이는가’는 보장하지 않는다.

동기화는 베타적 실행뿐 아니라 스레드 사이의 안정적인 통신에 꼭 필요하다.

동기화에 실패한 공유 가변 데이터

공유 중인 가변 데이터를 비록 원자적으로 읽고 쓸 수 있을지라도 동기화에 실패하면 처참한 결과로 이어질 수 있다.

잘못된 코드 - 이 프로그램은 오래 실행될 것이다.

public class StopThread {
    private static boolean stopRequested;

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
             int i = 0;
             while (!stopRequested)
                 i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

Thread.stop 메서드는 안전하지 않아. 이미 오래전에 사용 자제 API로 지정 되었으며, 자바 11에서는 제거되었다. (이 메서드를 사용하면 데이터가 훼손될 수 있다.)

이 프로그램은 메인 스레드가 1초 후 stopRequested를 true로 설정하면 backgroundThread는 반복문을 빠져나올 것처럼 보일 것이지만 영원히 수행된다.

잘못된 원인?

원인은 동기화에 있다. 동기화하지 않으면 메인 스레드가 수정한 값을 백그라운드 스레드가 언제쯤에나 보게 될지 보증할 수 없다.
동기화가 빠지면 가상머신이 위의 코드를 다음과 같은 최적화를 수행할 수도 있다.

원래 코드

while (!stopRequested)
    i++;

가상머신이 이해하고 최적화한 코드

if (!stopRequested)
    while (true)
        i++;

OpenJDK 서버 VM이 실제로 적용하는 끌어올리기(hoisting)라는 최적화 기법이다. 이 결과 프로그램은 응답 불가(liveness failure) 상태가 되어 더 이상 진전이 없다.

해결방법

stopRequested 필드를 동기화해 접근하면 이 문제를 해결할 수 있다.

적절히 동기화해 스레드가 정상 종료

public class StopThread {
    private static boolean stopRequested;

    private static synchronized void requestStop() {
        stopRequested = true;
    }

    private static synchronized boolean stopRequested() {
        return stopRequested;
    }

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
             int i = 0;
             while (!stopRequested())
                 i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

쓰기 메서드(requestStop)와 읽기 메서드(stopRequested) 모두를 동기화(synchronized)했음에 주목하자.

쓰기 메서드만 동기화 해서는 충분하지 않다. 쓰기와 읽기 모두가 동기화되지 않으면 동작을 보장하지 않는다.

volatile

stopRequested 필드를 volatile으로 선언하면 동기화를 생략해도 된다. volatile 한정자는 배타적 수행과는 상관없지만 항상 가장 최근에 기록된 값을 읽게 됨을 보장한다.

volatile필드 사용

public class StopThread {
    private static volatile boolean stopRequested;

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
          int i = 0;
          while (!stopRequested)
            i++;
        });
        backgroundThread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

volatile 주의할 점

volatile은 주의해서 사용해야한다.

동기화가 필요

private static volatile int nextSerialNumber = 0;

public static int generateSerialNumber() {
    return nextSerialNumber++;
}

이 generateSerialNumber메서드는 매번 고유한 값을 반환할 의도로 만들어졌다. 하지만 이 역시 동기화 없이는 올바로 동작하지 않는다.

문제는 증가 연산자(++)다. 이 연산자는 코드상으로는 하나지만 실제로는 nextSerialNumber필드에 두번 접근한다.

먼저 값을 읽고, 1을 증가한 새로운 값을 저장하는 것이다. 만약 두 번째 스레드가 이 값을 읽는 사이를 비집고 들어온다면 첫 번째 스레드와 똑같은 값을 돌려받게 된다.

프로그램이 잘못된 결과를 계산해내는 이런 오류를 안전 실패(safety failure)라고 한다.

해결법

generateSerialNumber메서드에 synchronized 한정자를 붙이면 이 문제가 해결된다. 동시에 호출해도 서로 간섭하지 않으며 이전 호출이 변경한 값을 읽게 된다.

하지만 메서드에 synchronized를 붙였다면 nextSerialNumber 필드에서는 volatile을 제거해야 한다. int나 long을 사용해서 메서드를 더 견고하게 할 수 있다.

java.util.concurrent.atomic

자바에는 java.util.concurrent.atomic 패키지가 있다. 자바의 기본 라이브러리 패키지 중 AtomicLong을 사용해보자.

이 패키지에는 락 없이도(lock-free) 스레드 안전한 프로그래밍을 지원하는 클래스들이 담겨있다. 성능도 동기화 버전보다 우수하다.

atomic을 이용한 락-프리 동기화

private static final AtomicLong nextSerialNum = new AtomicLong();

public static long generateSerialNumber() {
    return nextSerialNum.getAndIncrement();
}

부분 동기화

한 스레드에서 데이터를 다 수정한 후 다른 스레드에 공유할 때는 해당 객체에서 공유하는 부분만 동기화해도 된다. 그러면 그 객체를 다시 수정할 일이 생기기 전까지 다른 스레드들은 동기화 없이 자유롭게 값을 읽어갈 수 있다.

이런 객체를 사실상 불변(effectively immutable)이라 하고 다른 스레드에 이런 객체를 건네는 행위를 안전 발행(safe publication)

클래스 초기화 과정에서 객체를 정적 필드, volatile 필드, final 필드, 혹은 보통의 락을 통해 접근하는 필드에 저장해도 된다. 그리고 동시성 컬렉션에 저장하는 방법도 있다.

가장 좋은 방법

이번 아이템에서 언급된 문제들을 피하는 가장좋은 방법은 애초에 가변 데이터를 공유하지 않는 것이다. 불변 데이터만 공유하거나 아무것도 공유하지 말자.
가변 데이터는 단일 스레드에서만 쓰도록 하자.

Related posts