아이템 79. 과도한 동기화는 피하라

[mbyul]

78 에서 충분하지 못한 동기화의 피해를 다뤘다면, 이번엔 반대 상황

과도한 동기화는

• 동기화는 성능을 떨어트리고
• 교착상태에 빠트리고
• 심지어 예측할 수 없는 동작을 낳음. (응답 불가, 안전 실패)

동기화 메서드나 동기화 블록 안에서는 클라이언트에게 제어권을 넘기지 말 것

• 동기화 영역 내부에서는 재정의된 메소드 호출하지 않아야 하며,
• 함수 객체의 형태로 클라이언트가 제공하는 메소드도 호출하지 말아야 함.
• 이런 메서드들을 외계인 메서드(alien method)라고 부름
  • 무슨 일을 할지 모르니, 이 메서드가 예외를 발생시키거나, 교착상태를 만들거나, 데이터를 훼손시킬 수 있음

잘못된 코드(예외 발생) - 동기화 블록 안에서 외계인 메서드 호출

public class ObservableSet<E> extends ForwardingSet<E> {
   ...
    private final List<SetObserver<E>> observers = new ArrayList<SetObserver<E>> ();
   ...
    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);
            }
        }
    }

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

    @Override
    public boolean addAll(Collection<? extends E> c) {
        boolean result = false;
        for (E element : c) {
            result |= add(element); // notifyElementAdded를 호출
        }
        return result;
    }
}

public interface SetObserver<E> { // 요소가 Set에 추가될 때 호출된다(call back)
   void added(ObservableSet<E> set, E element);
}

• 어떤 집합(Set)을 감싼 래퍼 클래스이고, 이 클래스의 클라이언트는 집합에 원소가 추가되면 알림을 받을 수 있는 관찰자 패턴
• observers(관찰자)는 addObserver 메소드를 호출하여 통지(요소가 Set에 추가되었다는)를 구독하며, removeObserver 메소드를 호출하여 구독을 해지

public static void main(String[] args) {
    ObservableSet<Integer> set = new ObservableSet<>(new HashSet<>());
    set.addObserver(new SetObserver<>() {
        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 출력 후 Observer 구독해제 후 종료될 걸로 예상
• 결과 : 0~23 출력 후 ConcurrentModificationException 발생
• 문제 : List의 observers를 순환 처리하는 과정 중에 notifyElementAdded 메소드 호출이 포함되어 있다는 것
• 원인 : added 메서드에서 -> ObservableSet.removeObserver 호출 -> observers.remove 호출하는데 여기서 문제 발생
  • List의 전체 요소를 순환 처리하는 과정 중에 요소를 삭제하려고 한 것이 문제
  • notifyElementAdded 메소드의 반복 처리는 동시적 변경을 막는 동기화 블록 안에 있음
  • 반복처리를 하고 있는 스레드는 Set으로 다시 호출되어 자신의 observers List를 변경하는 것을 막지 못함

잘못된 코드(교착 상태) - 쓸데없이 백그라운드 스레드를 사용하는 관찰자

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

    // 실행 (executor) 서비스를 사용하는 observer(관찰자)
    set.addObserver(new SetObserver<>() {
        public void added(ObservableSet<Integer> s, Integer e) {
            System.out.println(e);
            if(e == 23) {
                ExecutorService exec = Executors.newSingleThreadExecutor();
                try {

                    // 여기서 lock 발생 (메인 스레드는 작업을 기다리고 있음)
                    // 특정 태스크가 완료되기를 기다림 (submit().get()) (#80 참고)
                    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);
    }
}

• 이 프로그램은 예외는 나지 않지만 교착상태에 빠짐
• 백그라운드 스레드가 s.removeObserver를 호출하면 Observer를 잠그려 시도하지만 락을 얻을 수 없음
  • 메인스레드가 이미 락을 쥐고 있기 때문 - removeObserver는 synchronized 키워드가 달려있어서 실행 시 락이 걸림
• 그와 동시에 메인 스레드는 백그라운드 스레드가 Observer를 제거하기만을 기다리는 중

예외 및 교착상태 해결법 - 1

• 외계인 메소드 호출을 동기화된 블록 밖으로 옮기면 됨

// 동기화된 블록 밖으로 외계인 메소드를 옮긴다
private void notifyElementAdded(E element) {
         List<SetObserver<E>> snapshot = null; 
         synchronized(observers) {
             snapshot =new ArrayList<SetObserver<E>> (observers);
         }

         for (SetObserver<E> observer : snapshot)
                 observer.added(this, element) ;
}

예외 및 교착상태 해결법 - 2

• 자바의 동시성 지원 컬렉션 라이브러리 CopyOnWriteArrayList 사용
  • ArrayList를 구현한 클래스로, 내부를 변경하는 작업은 항상 깨끗한 복사본을 만들어 수행하도록 구현

성능 측면

• 과도한 동기화는 병렬로 실행할 기회를 잃고, 모든 코어가 메모리를 일관되게 보기 위한 지연시간이 발생
  • 가상머신의 코드 최적화를 제한한다는 점도 과도한 동기화의 또다른 숨은 비용

그럼 어떻게?

• 가변 클래스를 작성하려거든 다음 두 선택지 중 하나를 따르자.
  1. 동기화를 전혀 하지 말고, 그 클래스를 동시에 사용해야 하는 클래스가 외부에서 알아서 동기화하게 하자.
     • ex) java.util
  2. 동기화를 내부에서 수행해 스레드 안전한 클래스로 만들자 (#82)
     • 단, 클라이언트가 외부에서 객체 전체에 락을 거는 것보다 동시성을 월등히 개선할 수 있을 때만 두 번째 방법을 선택
     • ex) java.util.concurrent

사례

1. StringBuffer는 거의 단일 스레드에서 쓰였음에도 내부적으로 동기화를 수행
   • 성능상의 이수로 뒤늦게 StringBuilder가 등장한 이유이기도 함
2. java.util.Random은 동기화하지 않은 버전인 java.util.concurrent.ThreadLocalRandom으로 대체

그래서 뭘 쓰라고??

• 선택하기 어렵다면 동기화하지 말고, 대신 문서에 '스레드 안전하지 않다'고 명기하자

정리

• 교착상태와 데이터 훼손을 피하려면 동기화 영역 안에서 외계인 메서드를 절대 호출하지 말것
• 동기화 영역 안에서의 작업은 최소한으로 줄이자.
• 가변클래스를 설계할 때는 스스로 동기화해야 할지 고민하자.
• 멀티코어 세상인 지금은 과도한 동기화를 피하는게 중요
• 합당한 이유가 있을 때만 내부에서 동기화하고, 동기화했는지 여부를 문서에 명확히 밝히자 #82