Effective Java 3/E #1 - Item 78 ~ 79

💡 해당 포스팅에서 소개된 예제 코드들은 여기에서 확인할 수 있다.

개요

이펙티브 자바 내용을 정리하게 된 계기?

2년 전에 이펙티브 자바 스터디를 했고 이 활동을 포트폴리오에 넣었다. 그랬더니 회사 규모와 상관없이 대부분의 인터뷰에서 이펙티브 자바에서 인상 깊었던 내용 혹은 기억 나는 내용에 대한 질문을 받았다. 오래 전에 했던 스터디라 기억 나는 내용이 거의 없었고, 이를 계기로 책 '이펙티브 자바'를 다시 한 번 공부할 필요성이 있다고 생각했다.

이전 스터디에서는 아이템 1부터 차례로 공부했지만, 이번에는 내가 공부하고 있는 주제와 관련된 아이템을 공부하고 블로그 글로 정리하려 한다.

synchronized, volatile, atomic object에 대해 모른다면 Java에서 Thread-Safe하게 구현하기 포스팅을 먼저 읽는 것을 추천한다.

Item 78: 공유 중인 가변 데이터는 동기화해 사용하라

동기화는 배타적인 실행과 스레드 사이의 안정적인 통신에 꼭 필요하다.

배타적인 실행

배타적 실행을 통해 객체를 하나의 일관된 상태에서 다른 일관된 상태로 변화시킨다. 하나의 스레드가 공유 중인 가변 데이터를 변경하는 사이에 다른 스레드가 해당 데이터를 확인하지 못하게 한다.

스레드 간 통신

동기화된 메서드나 블록에 들어간 스레드가 같은 락의 보호 하에 수행된 모든 이전 수정의 최종 결과를 보게 해준다. 하나의 스레드가 공유 중인 가변 데이터를 변경하면 다른 스레드에게 변경된 데이터가 보여야 한다.

배타적인 실행으로 원자성을, 스레드 간 통신으로 가시성을 확보할 수 있다.

예제 #1

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

그렇다면 원자적 데이터를 읽고 쓸 때 동기화가 필요 없을까? 아래 코드의 실행 결과를 예측해보자.

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;
    }
}

프로그램은 while 문을 빠져나오지 못하고 계속 수행된다. JLS 17.3에 컴파일러는 non-volatile boolean 필드를 한 번 읽어온 뒤 캐시한 값을 재사용하기 때문에 다른 스레드가 필드값을 변경하더라도 반복문은 영원히 종료되지 않는다고 나와 있다.

이처럼 공유 중인 가변 데이터를 비록 원자적으로 읽고 쓸 수 있을지라도 동기화에 실패하면 예상치 못한 문제가 발생할 수 있다. 앞서 언급했듯 동기화의 역할 중 하나는 "안정적인 스레드 간 통신"이다. 동기화하지 않으면 메인 스레드가 수정한 값을 백그라운드 스레드가 언제 보게 될지 알 수 없다.

그렇다면 어떻게 프로그램을 개선할 수 있을까?

예제 #1: synchronized

synchronized 한정자를 사용해 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();
    }
}

프로그램은 예상했던 대로 1초 후 종료된다. 쓰기 메서드(requestStop)와 읽기 메서드(stopRequested)는 원자적으로 동작하기 때문에 이 코드에서 동기화는 스레드 간 통신 목적으로만 사용되었다고 볼 수 있다.

예제 #1: volatile

stopRequested 필드를 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;
    }
}

synchronized 예제와 마찬가지로 프로그램은 1초 후 종료된다.

예제 #2

volatile은 주의해서 사용해야 한다. 아래 코드를 실행하면 어떤 값이 출력될까?

public class SerialNumber {

    private static final ExecutorService THREAD_POOL = Executors.newFixedThreadPool(10);

    private static volatile int nextSerialNumber = 0;

    private static int generateNextSerialNumber() throws InterruptedException {
        Thread.sleep(1);
        return nextSerialNumber++;
    }

    public static void main(String[] args) throws InterruptedException {
        int N = 30;
        CountDownLatch latch = new CountDownLatch(N);

        for (int i = 0; i < N; i++) {
            THREAD_POOL.execute(() -> {
                try {
                    generateNextSerialNumber();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                latch.countDown();
            });
        }

        latch.await();
        System.out.println(nextSerialNumber);
    }
}

30이 출력되어야 할 것 같지만 프로그램을 실행해보면 30에 못 미치는 값이 출력된다. volatile 한정자는 항상 가장 최근에 기록된 값을 읽게 됨을 보장하는데 왜 이런 결과가 나온걸까?

문제는 증가 연산자(++)다. 이 연산자는 코드 상으로는 하나지만 실제로는 nextSerialNumber 필드에 두 번 접근한다. 먼저 값을 읽고, 그런 다음 1 증가한 새로운 값을 저장하는 것이다. 만약 두 번째 스레드가 이 두 접근 사이를 비집고 들어와 값을 읽어가면 첫 번째 스레드와 동일한 값을 돌려받게 된다.

IntelliJ에서도 아래와 같이 nextSerialNumber++가 atomic하지 않은 연산이라는 warning을 띄워준다.

volatile은 가시성을 보장하지만 원자성은 보장하지 않기 때문에 주의해서 사용해야 한다.

예제 #2: synchronized

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

public class SerialNumberSynchronized {

    private static final ExecutorService THREAD_POOL = Executors.newFixedThreadPool(10);

    private static int nextSerialNumber = 0;

    private static synchronized int generateNextSerialNumber() throws InterruptedException {
        Thread.sleep(1);
        return nextSerialNumber++;
    }

    public static void main(String[] args) throws InterruptedException {
        int N = 30;
        CountDownLatch latch = new CountDownLatch(N);

        for (int i = 0; i < N; i++) {
            THREAD_POOL.execute(() -> {
                try {
                    generateNextSerialNumber();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                latch.countDown();
            });
        }

        latch.await();
        System.out.println(nextSerialNumber);
    }
}

synchronized는 원자성과 가시성을 모두 보장한다.

예제 #2: atomic object

또 다른 방법으로는 java.util.concurrent.atomic 패키지의 AtomicInteger를 사용할 수 있다. synchronized는 Lock을 사용해 동기화하지만 이 패키지의 클래스는 락 없이 스레드 안전한 프로그래밍을 지원하기 때문에 성능도 뛰어나다.

public class SerialNumberAtomic {

    private static final ExecutorService THREAD_POOL = Executors.newFixedThreadPool(10);

    private static final AtomicInteger nextSerialNumber = new AtomicInteger();

    private static int generateNextSerialNumber() throws InterruptedException {
        Thread.sleep(1);
        return nextSerialNumber.getAndIncrement();
    }

    public static void main(String[] args) throws InterruptedException {
        int N = 30;
        CountDownLatch latch = new CountDownLatch(N);

        for (int i = 0; i < N; i++) {
            THREAD_POOL.execute(() -> {
                try {
                    generateNextSerialNumber();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                latch.countDown();
            });
        }

        latch.await();
        System.out.println(nextSerialNumber);
    }
}

atomic object는 원자성과 가시성을 모두 보장한다.

요약

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

💡 여러 스레드가 가변 데이터를 공유한다면 그 데이터를 읽고 쓰는 동작은 반드시 동기화해야 한다.

Item 79: 과도한 동기화는 피하라

아이템 78에서 충분하지 않은 동기화의 문제를 다뤘다면, 이번 아이템에서는 반대 상황을 다룬다. 과도한 동기화는 성능을 저하시키고, 교착 상태에 빠뜨리거나 데이터를 훼손할 수 있다.

이러한 문제가 발생하는 것을 막으려면 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안된다. 예를 들어 동기화된 영역 안에서는 재정의할 수 있는 메서드는 호출하면 안 되며, 클라이언트가 넘겨준 함수 객체를 호출해서도 안 된다. 이런 메서드는 외계인 메서드라 한다.

아래에 나오는 예시들을 제대로 이해하고 싶다면 포스팅 상단에 걸어둔 링크를 통해 전체 코드를 확인하는 것을 추천한다.

예제 #1

아래 ObservableSet은 어떤 집합(Set)을 감싼 래퍼 클래스이고, 이 클래스의 클라이언트는 집합에 원소가 추가되면 알림을 받을 수 있다. 관찰자 패턴

public class ObservableSet<E> extends ForwardingSet<E> {

    public ObservableSet(Set<E> set) {
        super(set);
    }

    private final List<SetObserver<E>> observers = new ArrayList<>();

    public void addObserver(SetObserver<E> observer) {
        synchronized (observers) {
            observers.add(observer);
        }
    }

    public boolean removeObserver(SetObserver<E> observer) {
        synchronized (observers) {
            return observers.remove(observer);
        }
    }

    private void notifyElementAdded(E element) {
        synchronized (observers) {
            for (SetObserver<E> observer : observers) {
                observer.added(this, element);
            }
        }
    }

    public boolean add(E element) {
        boolean added = super.add(element);
        if (added) {
            notifyElementAdded(element);
        }
        return added;
    }
}

관찰자들은 addObserver와 removeObserver 메서드를 호출해 구독을 신청하거나 해지한다. 두 경우 모두 아래 콜백 인터페이스의 인스턴스를 인자로 받는다.

@FunctionalInterface
public interface SetObserver<E> {
	// ObservableSet에 원소가 더해지면 호출된다.
    void added(ObservableSet<E> set, E element);
}

아래 프로그램은 집합에 추가된 정수값을 출력하다가 그 값이 23이면 구독을 해지하는 관찰자(SetObserver)를 추가했다. 이 프로그램을 실행하면 어떤 결과가 나올까?

public static void main(String[] args) {
    ObservableSet<Integer> set = new ObservableSet<>(new HashSet<>());

    set.addObserver(new SetObserver<Integer>() {
        @Override
        public void added(ObservableSet<Integer> s, Integer e) {
            System.out.println(e);
            if (e == 23) {
                s.removeObserver(this);
            }
        }
    });

    for (int i = 0; i < 100; i++) {
        set.add(i);
    }
}

0부터 23까지 출력한 후 관찰자 자신을 구독 해지한 다음 조용히 종료되는 것이 아니라 ConcurrentModificationException 예외가 발생한다!

프로그램 실행 순서를 살펴보자. main 함수의 for 문에서 i = 23일 때

• (1) set.add(i)를 호출한다.
• (2) ObservableSet의 set에 원소를 추가한 뒤 notifyElementAdded를 호출한다.
• (3) ObservableSet의 observers 리스트를 순회하며 added를 호출한다.
• (4) 23을 출력하고 removeObserver를 호출한다.
• (5) observers 리스트에서 원소(observer)를 삭제한다.

// (1) main 
set.add(i);

// (2) ObservableSet
public boolean add(E element) {
    boolean added = super.add(element);
    if (added) {
        notifyElementAdded(element);
    }
    return added;
}

// (3) ObservableSet
private void notifyElementAdded(E element) {
    synchronized (observers) {
        for (SetObserver<E> observer : observers) {
            observer.added(this, element);
        }
    }
}

// (4) main
public void added(ObservableSet<Integer> s, Integer e) {
    System.out.println(e);
    if (e == 23) {
        s.removeObserver(this);
    }
}

// (5) ObservableSet
public boolean removeObserver(SetObserver<E> observer) {
    synchronized (observers) {
        return observers.remove(observer);
    }
}

결국 동기화 블록 안에서 observers 리스트를 순회하는 도중에 원소를 삭제했기 때문에 에외가 발생한 것이다. 이는 허용되지 않은 동작이며 ConcurrentModificationException에도 명시되어 있다.

동기화 메서드(notifyElementAdded) 안에서 클라이언트가 넘겨준 함수 객체(added)를 호출하기 때문에 문제가 발생했다!

예제 #2

이번엔 removeObserver를 메인 스레드에서 직접 호출하지 않고 실행자 서비스를 사용해 다른 스레드가 호출하도록 했다. 실행 결과는 어떨까?

public class ObservableTest3 {

    public static void main(String[] args) {
        ObservableSet<Integer> set = new ObservableSet<>(new HashSet<>());

        set.addObserver(new SetObserver<Integer>() {
            @Override
            public void added(ObservableSet<Integer> s, Integer e) {
                System.out.println(e);
                if (e == 23) {
                	// removeObserver 호출을 메인 스레드가 아닌 다른 스레드에서 호출하도록 한다.
                    ExecutorService exec = Executors.newSingleThreadExecutor();
                    try {
                        exec.submit(() -> s.removeObserver(this)).get();
                    } catch (ExecutionException | InterruptedException ex) {
                        throw new AssertionError(ex);
                    } finally {
                        exec.shutdown();
                    }
                }
            }
        });

        for (int i = 0; i < 100; i++) {
            set.add(i);
        }
    }
}

이 프로그램을 실행하면 예외가 발생하진 않지만 교착상태에 빠진다. 앞서 살펴본 프로그램 실행 순서 중 일부이다. 메인 스레드가 notifyElementAdded 메서드를 호출하며 락을 갖고 있고, 그 다음에 다른 스레드가 생성되어 removeObserver를 실행하지만 이미 메인 스레드가 락을 갖고 있기 때문에 락을 얻을 수 없다. 이와 동시에 메인 스레드는 백그라운드 스레드가 관찰자를 제거하기만을 기다린다.

// (3) ObservableSet
private void notifyElementAdded(E element) {
    synchronized (observers) {
        for (SetObserver<E> observer : observers) {
            observer.added(this, element);
        }
    }
}

// (4) main
public void added(ObservableSet<Integer> s, Integer e) {
    System.out.println(e);
    if (e == 23) {
        ExecutorService exec = Executors.newSingleThreadExecutor();
        try {
            exec.submit(() -> s.removeObserver(this)).get();
        } catch (ExecutionException | InterruptedException ex) {
            throw new AssertionError(ex);
        } finally {
            exec.shutdown();
        }
    }
}

// (5) ObservableSet
public boolean removeObserver(SetObserver<E> observer) {
    synchronized (observers) {
        return observers.remove(observer);
    }
}

예제 #3

외계인 메서드 호출을 동기화 블록 바깥으로 옮기면 문제를 해결할 수 있다! notifyElementAdded 메서드에서 관찰자 리스트를 복사해 쓰면 락 없이도 안전하게 순회할 수 있다.

private void notifyElementAdded(E element) {
    List<SetObserver<E>> snapShot = null;
    synchronized (observers) {
        snapShot = new ArrayList<>(observers);
    }
    for (SetObserver<E> observer : snapShot) {
        observer.added(this, element);
    }
}

이 방식을 적용하면 앞서 살펴본 두 예제에서 발생했던 예외와 교착상태가 나타나지 않는 것을 확인할 수 있다. 이렇게 동기화 영역 바깥에서 호출되는 외계인 메서드를 열린 호출(open call)이라 한다. 외계인 메서드는 얼마나 오래 실행될지 알 수 없으므로 동기화 영역 안에서 호출된다면 그동안 다른 스레드는 보호된 자원을 사용하지 못하고 대기해야 한다. 따라서 열린 호출은 실패 방지 효과 외에도 동시성 효율을 크게 개선해준다.

예제 #4

외계인 메서드 호출을 동기화 블록 바깥으로 옮기는 것보다 더 나은 방법은 자바의 동시성 컬렉션 라이브러리의 CopyOnWriteArrayList를 사용하는 것이다.

CopyOnWriteArrayList는 ArrayList를 구현한 클래스로, 내부를 변경하는 작업은 항상 복사본을 만들어 수행하도록 구현되었다. 따라서 배열을 수정할 일이 많다면 성능 이슈가 발생하겠지만, 순회할 때 락이 필요 없어 매우 빠르다.

public class ObservableSet<E> extends ForwardingSet<E> {

    public ObservableSet(Set<E> set) {
        super(set);
    }

    private final List<SetObserver<E>> observers = new CopyOnWriteArrayList<>();

    public void addObserver(SetObserver<E> observer) {
        observers.add(observer);
    }

    public boolean removeObserver(SetObserver<E> observer) {
        return observers.remove(observer);
    }

    private void notifyElementAdded(E element) {
        for (SetObserver<E> observer : observers) {
            observer.added(this, element);
        }
    }

    public boolean add(E element) {
        boolean added = super.add(element);
        if (added) {
            notifyElementAdded(element);
        }
        return added;
    }
}

마찬가지로 앞서 살펴본 두 예제에서 발생했던 예외와 교착상태가 나타나지 않는 것을 확인할 수 있다.

요약

기본 규칙은 동기화 영역에서는 가능한 일을 적게 하는 것이다. 또한, 교착상태와 데이터 훼손을 피하려면 동기화 영역 안에서 외계인 메서드를 절대 호출하지 말자.

Reference

• 이펙티브 자바 3/E
• https://docs.oracle.com/javase/specs/jls/se17/html/jls-17.html#jls-17.4.3
• https://stackoverflow.com/questions/11970428/how-to-understand-happens-before-consistent
• https://stackoverflow.com/questions/106591/what-is-the-volatile-keyword-useful-for/59498520#59498520
• https://stackoverflow.com/questions/65527237/java-memory-model-a-jls-statement-about-sequential-consistency-seems-incorrect
• https://stackoverflow.com/questions/11970428/how-to-understand-happens-before-consistent
• https://stackoverflow.com/questions/17108541/happens-before-relationships-with-volatile-fields-and-synchronized-blocks-in-jav
• http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html