René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"아이템 79. 과도한 동기화는 피하라","articleBody":"### Discussed in https://github.com/orgs/Study-2-Effective-Java/discussions/191\r\n\r\n\u003cdiv type='discussions-op-text'\u003e\r\n\r\n\u003csup\u003eOriginally posted by **JoisFe** April  2, 2023\u003c/sup\u003e\r\n# 아이템 79. 과도한 동기화는 피하라\r\n\r\n- #182 에서 `충분하지 못한 동기화의 피해` 에 다뤘는데 이번 주제는 반대 상황을 다룸\r\n\r\n## 과도한 동기화의 문제점\r\n- 성능을 떨어뜨림\r\n- 교착 상태에 빠뜨림\r\n- 예측할 수 없는 동작을 낳기도 함\r\n\r\n### 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안됨!\r\n\r\n- EX) 동기화된 영역 안에서는 재정의할 수 있는 메서드를 호출하면 안되고 클라이언트가 넘겨준 함수 객체를 호출해서도 안됨 (#48 참고)\r\n- 동기화된 영역을 포함한 클래스 관점에서는 이런 메서드는 모두 바깥 세상에서 온 외계인일 뿐\r\n- 해당 메서드가 무슨일을 할지 알지 못하고 통제할 수도 없음\r\n- 외계인 메서드 (alien method)가 하는 일에 따라 동기화된 영역은 예외를 일으키거나 교착상태에 빠지거나 데이터를 훼손할 수 있음\r\n\r\n``` java\r\npublic class ForwardingSet\u003cE\u003e implements Set\u003cE\u003e {\r\n\r\n    private final Set\u003cE\u003e s;\r\n\r\n    public ForwardingSet(Set\u003cE\u003e s) {\r\n        this.s = s;\r\n    }\r\n\r\n    @Override\r\n    public int size() {\r\n        return s.size();\r\n    }\r\n\r\n    @Override\r\n    public boolean isEmpty() {\r\n        return s.isEmpty();\r\n    }\r\n\r\n    @Override\r\n    public boolean contains(Object o) {\r\n        return s.contains(o);\r\n    }\r\n\r\n    @Override\r\n    public Iterator\u003cE\u003e iterator() {\r\n        return s.iterator();\r\n    }\r\n\r\n    @Override\r\n    public Object[] toArray() {\r\n        return s.toArray();\r\n    }\r\n\r\n    @Override\r\n    public \u003cT\u003e T[] toArray(T[] a) {\r\n        return s.toArray(a);\r\n    }\r\n\r\n    @Override\r\n    public boolean add(E e) {\r\n        return s.add(e);\r\n    }\r\n\r\n    @Override\r\n    public boolean remove(Object o) {\r\n        return s.remove(o);\r\n    }\r\n\r\n    @Override\r\n    public boolean containsAll(Collection\u003c?\u003e c) {\r\n        return s.containsAll(c);\r\n    }\r\n\r\n    @Override\r\n    public boolean addAll(Collection\u003c? extends E\u003e c) {\r\n        return s.addAll(c);\r\n    }\r\n\r\n    @Override\r\n    public boolean retainAll(Collection\u003c?\u003e c) {\r\n        return s.retainAll(c);\r\n    }\r\n\r\n    @Override\r\n    public boolean removeAll(Collection\u003c?\u003e c) {\r\n        return s.removeAll(c);\r\n    }\r\n\r\n    @Override\r\n    public void clear() {\r\n        s.clear();\r\n    }\r\n\r\n    @Override\r\n    public boolean equals(Object o) {\r\n        return s.equals(o);\r\n    }\r\n\r\n    @Override\r\n    public int hashCode() {\r\n        return s.hashCode();\r\n    }\r\n\r\n    @Override\r\n    public String toString() {\r\n        return s.toString();\r\n    }\r\n}\r\n```\r\n\r\n``` java\r\npublic class ObservableSet\u003cE\u003e extends ForwardingSet\u003cE\u003e{\r\n\r\n    public ObservableSet(Set\u003cE\u003e s) {\r\n        super(s);\r\n    }\r\n\r\n    private final List\u003cSetObserver\u003cE\u003e\u003e observers = new ArrayList\u003c\u003e();\r\n\r\n    public void addObserver(SetObserver\u003cE\u003e observer) {\r\n        synchronized (this.observers) {\r\n            this.observers.add(observer);\r\n        }\r\n    }\r\n\r\n    public boolean removeObserver(SetObserver\u003cE\u003e observer) {\r\n        synchronized (this.observers) {\r\n            return this.observers.remove(observer);\r\n        }\r\n    }\r\n\r\n    public void notifyElementAdded(E element) {\r\n        synchronized (this.observers) {\r\n            for (SetObserver\u003cE\u003e observer : observers) {\r\n                observer.added(this, element);\r\n            }\r\n        }\r\n    }\r\n\r\n    @Override\r\n    public boolean add(E e) {\r\n        boolean added = super.add(e);\r\n\r\n        if (added) {\r\n            notifyElementAdded(e);\r\n        }\r\n\r\n        return added;\r\n    }\r\n\r\n    @Override\r\n    public boolean addAll(Collection\u003c? extends E\u003e c) {\r\n        boolean result = false;\r\n\r\n        for (E e : c) {\r\n            result |= add(e);\r\n        }\r\n\r\n        return result;\r\n    }\r\n}\r\n```\r\n\r\n- 위 코드는 어떤 Set을 감싼 래퍼 클래스이고 이 클래스의 클라이언트는 집합에 원소가 추가되면서 알림을 받을 수 있는 코드임\r\n- 관찰자 패턴 (Observer Pattern) 임을 알 수 있다.\r\n- (원소가 제거되면 알려주는 기능은 생략한 코드)\r\n- Observer들은 addObserver와 removeObserver 메서드를 호출하여 subscription (구독) 를 신청하거나 해지 함\r\n\r\n``` java\r\n@FunctionalInterface\r\npublic interface SetObserver\u003cE\u003e {\r\n   \r\n    // ObservableSet에 원소가 더해지면 호출됨 \r\n    void added(ObservableSet\u003cE\u003e set, E element);\r\n}\r\n```\r\n\r\n- 해당 인터페이스는 구조적으로 BiConsumer\u003cObservableSet\u003cE\u003e, E\u003e와 같음\r\n- 그럼에도 커스텀 함수형 인터페이스를 정의한 이유는 이름이 더 직관적이고 다중 콜백을 지원하도록 확장할 수 있음\r\n- BiConsumer를 그대로 사용했더라고 해당 코드에서는 큰 문제 없음\r\n- #101 에 의하면 `표준 함수형 인터페이스를 사용하라`에 맞는대로라면 BiConsumer 를 사용하는게 맞았지 않나 생각함....\r\n\r\n\r\n### ObservableSet은 눈에 보기에 잘 동작할 것으로 보이나 문제가 있음\r\n\r\n``` java\r\npublic static void main(String[] args) {\r\n        ObservableSet\u003cInteger\u003e set = new ObservableSet\u003c\u003e(new HashSet\u003c\u003e());\r\n        \r\n        set.addObserver((s, e) -\u003e System.out.println(e));\r\n        \r\n        for (int i = 0; i \u003c 100; ++i) {\r\n            set.add(i);\r\n        }\r\n    }\r\n```\r\n\r\n- 해당 코드는 부터 99까지를 출력함\r\n\r\n``` java\r\nset.addObserver(new SetObserver\u003c\u003e() {\r\n            @Override\r\n            public void added(ObservableSet\u003cInteger\u003e set, Integer element) {\r\n                System.out.println(element);\r\n                \r\n                if (element == 23) {\r\n                    set.removeObserver(this);\r\n                }\r\n            }\r\n        });\r\n```\r\n\r\n- set에 추가된 정숫값을 출력하다가 그 값이 23이면 자기 자신을 제거(구독해지) 하는 observer를 추가한 코드이다\r\n- 이 코드는 0부터 23까지 출력한 후 observer 자신을 구독해지한 다음 조용히 종료할 것으로 예측됨\r\n- 하지만 실제로 실행해보면 23까지 출력한 다음 `ConcurrentModificationException`을 던짐\r\n\r\n![image](https://user-images.githubusercontent.com/90208100/229339413-f82ceedb-c771-48c8-92be-1d2e94030d22.png)\r\n\r\n### 참고\r\n- added 재정의를 람다를 사용하다가 익명클래스를 사용함\r\n- 이유는 s.removeObserver 메서드에 함수 객체 자신을 넘겨야 하기 때문\r\n- `람다는 자신을 참조할 수단이 없음` (#106 참고)\r\n\r\n다시 돌아와\r\n\r\n### ConcurrentModificationException을 던진 이유\r\n- observer의 added 메서드 호출이 일어난 시점이 notifyElementAdded가 observer의 리스트들을 순회하는 도중이었기 때문\r\n- added 메서드는 ObservableSet의 removeObserver 메서드를 호출했고 이 메서드는 다시 observers.remove 메서드를 호출\r\n- 여기서 문제가 발생\r\n- 리스트에서 원소를 제거하려 하는데 마침지금 이 리스트를 순회하는 도중인 것임\r\n- 즉 허용되지 않은 동작을 시도한 것임\r\n- notifyElementAdded 메서드에서 수행하는 순회는 동기화 블록 안에 있으므로 동시수정이 일어나지 않도록 보장하지만 정작 자신이 콜백을 거쳐 되돌아와 수정하는 것까지 막지는 못함\r\n\r\n``` java\r\n set.addObserver(new SetObserver\u003c\u003e() {\r\n            @Override\r\n            public void added(ObservableSet\u003cInteger\u003e set, Integer element) {\r\n                System.out.println(element);\r\n\r\n                if (element == 23) {\r\n                    ExecutorService exec = Executors.newSingleThreadExecutor();\r\n                    \r\n                    try {\r\n                        exec.submit(() -\u003e set.removeObserver(this)).get();\r\n                    } catch (ExecutionException | InterruptedException ex) {\r\n                        throw new AssertionError(ex);\r\n                    } finally {\r\n                        exec.shutdown();\r\n                    }\r\n                }\r\n            }\r\n        });\r\n```\r\n- 구독해지를 하는 observer를 작성하는데 removeObserver를 직접 호출하지  않고 실행자 서비스 (ExecutorService)를 사용해서 다른 스레드한테 부탁할 것임 (아이템 80 참고)\r\n- 그러나 이 코드로 실행하면 예외는 나지 않지만 교착 상태에 빠짐\r\n\r\n### 교착 상태에 빠지는 이유\r\n- 백그라운드 스레드가 s.removeObserver를 호출하면 observer를 잠그려 시도하지만 락을 얻을 수 없음\r\n- 메인 스레드가 이미 락을 쥐고 있기 때문\r\n- 그와 동시에 메인 스레드는 백그라운드 스레드가 observer를 제거하기만을 기다리는 중\r\n- --\u003e 교착 상태\r\n- (사실 observer가 자신을 구독해지하는 데 굳이 백그라운드 스레드를 이용할 이유가 없는 억지스러운 예지만 이러한 문제가 일어날 수 있음을 보여주기 위한 예)\r\n- 실제 시스템 (특히 GUI 툴킷)에서도 동기화된 영역 안에서 외계인 메서드를 호출하여 교착상태에 빠지는 사례가 자주 있음\r\n\r\n### 위와 똑같은 상황이지만 불변식이 임시로 깨진 경우\r\n- 자바 언어의 락은 재진입(reentrant) 을 허용하므로 교착상태에 빠지지는 않음\r\n- 예외를 발생시킨 첫 번째 예에서라면 외계인 메서드를 호출하는 스레드는 이미 락을 쥐고 있으므로 다음번 락 획득도 성공함\r\n- (그 락이 보호하는 데이터에 대해 개념적으로 관련이 없는 다른 작업이 진행 중인데도 성공함)\r\n- 이것 때문에 매우 참혹한 결과가 빚어질 수 있음\r\n- 왜냐하면 락이 제 구실을 하지 못했기 때문\r\n- 재진입 가능 락은 객체 지향 멀티스레드 프로그램을 쉽게 구현할 수 있도록 해주지만 응답 불가 (교착 상태)가 될 상황을 안전 실패 (데이터 훼손)로 변모시킬 수 있기 때문\r\n\r\n### 해결 방법\r\n- 외계인 메서드 호출을 동기화 블록 바깥으로 옮기면 됨\r\n- notifyElementAdded 메서드에서는 observer 리스트를 복사해 쓰면 락 없이도 안전하게 순회할 수 있음\r\n- 이 방식을 적용하면 앞의 예제의 문제점인 예외 발생과 교착 상태 증상이 사라짐\r\n\r\n``` java\r\npublic void notifyElementAdded(E element) {\r\n        List\u003cSetObserver\u003cE\u003e\u003e snapshot = null;\r\n        \r\n        synchronized (this.observers) {\r\n            snapshot = new ArrayList\u003c\u003e(this.observers);\r\n        }\r\n\r\n        for (SetObserver\u003cE\u003e observer : snapshot) {\r\n            observer.added(this, element);\r\n        }\r\n    }\r\n```\r\n\r\n![image](https://user-images.githubusercontent.com/90208100/229341046-cb01f5fb-e23d-4735-8789-76b78e2c632e.png)\r\n\r\n- 사실 외계인 메서드 호출을 동기화 블록 바깥으로 옮기는 더 나은 방법이 있음\r\n- 자바의 동시성 컬렉션 라이브러리 CopyOnWriteArrayList가 정확히 이 목적으로 특별히 설계된 것\r\n- 메서드 이름을 보면 알 수 있듯 ArrayList를 구현한 클래스로 내부를 변경하는 작업은 항상 깨끗한 복사본을 만들어 수행하도록 구현\r\n- 내부의 배열은 절대 수정되지 않으니 순회할 때 락이 필요 없어 매우 빠름\r\n- 다른 용도로 쓰인다면 CopyOnWriteArrayList는 끔찍하게 느려지겠지만 수정할 일은 드물고 순회만 빈번히 일어나는 Observer 리스트 용도로는 최적\r\n\r\n``` java\r\npublic class ObservableSet\u003cE\u003e extends ForwardingSet\u003cE\u003e{\r\n\r\n    public ObservableSet(Set\u003cE\u003e s) {\r\n        super(s);\r\n    }\r\n\r\n    private final List\u003cSetObserver\u003cE\u003e\u003e observers = new CopyOnWriteArrayList\u003c\u003e();\r\n\r\n    public void addObserver(SetObserver\u003cE\u003e observer) {\r\n        this.observers.add(observer);\r\n    }\r\n\r\n    public boolean removeObserver(SetObserver\u003cE\u003e observer) {\r\n        return this.observers.remove(observer);\r\n    }\r\n\r\n    public void notifyElementAdded(E element) {\r\n        for (SetObserver\u003cE\u003e observer : observers) {\r\n            observer.added(this, element);\r\n        }\r\n    }\r\n\r\n~~~\r\n```\r\n\r\n- 위 코드는 ObservableSet을 CopyOnWriteArrayList를 사용해 다시 구현하여 변경한 것임\r\n### 명시적으로 동기화한 곳이 사라졌다는 것이 중요한 포인트!\r\n\r\n- 코드가 동기화 영역 바깥에서 호출되는 외계인 메서드를 열린 호출 (open call) 이라 함\r\n- 외계인 메서드는 얼마나 오래 실행될지 알 수 없는데 동기화 영역 안에서 호출한다면 그 동안 다른 스레드는 보호된 자원을 사용하지 못하고 대기해야만 함\r\n- 따라서 열린 호출은 실패 방지 효과 외에도 동시성 효율을 크게 개선시켜줌\r\n\r\n## 동기화 규칙\r\n### 기본 규칙은 동기화 영역에서는 가능한 한 일을 적게 하는 것!\r\n- 락을 얻고 공유 데이터를 검사하고 필요하면 수정하고 락을 놓음\r\n- 오래 걸리는 작업이라면 #182 의 지침을 어기지 않으면서 동기화 영역 바깥으로 옮기는 방법을 찾아봐야함\r\n\r\n## 과도한 동기화와 성능\r\n- 자바의 동기화 비용은 빠르게 낮아져 왔지만 과도한 동기화를 피하는 일은 오히려 과거 어느 때보다 중요!\r\n- 멀티코어가 일반화된 오늘날 과도한 동기화가 초래하는 진짜 비용은 락을 얻는 데 드는 CPU 시간이 아님\r\n- 바로 경쟁하느라 낭비하는 시간 즉 병렬로 실행할 기회를 잃고 모든 코어가 메모리를 일관되게 보기 위한 지연시간이 진짜 비용임!\r\n- 가상 머신의 코드 최적화를 제한한다는 점도 과도한 동기화의 또 다른 숨은 비용\r\n\r\n## 가변 클래스를 작성하는 2가지 선택지\r\n1. 동기화를 전혀 하지 말고 그 클래스를 동시에 사용해야 하는 클래스가 외부에서 알아서 동기화하게 하기\r\n2. 동기화를 내부에서 수행해 스레드 안전한 클래스로 만들기 (아이템 82 참고)\r\n\r\n- 단 클라이언트가 외부에서 객체 전체에 락을 거는 것보다 동시성을 월등히 개선할 수 있을 때만 두 번째 방법 선택해야 함\r\n- java.util은 (구식이 된 Vector와 Hashtable을 제외) 첫 번째 방식을 취했음\r\n- java.util.concurrent는 두 번째 방식을 취했음 (아이템 81 참고)\r\n\r\n### 자바도 초장기에는 이 지침을 따르지 않은 클래스가 많았음\r\n- StringBuffer 인스턴스 경우 거의 항상 단일 스레드에서 쓰였음에도 내부적으로 동기화를 수행\r\n- 뒤늦게 StringBuffer가 등장한 이유기도 함 (StringBuilder는 그저 동기화하지 않은 StringBuffer)\r\n- 비슷한 이유로 스레드 안전한 의사 난수 발생기인 java.util.Random은 동기화하지 않는 버전인 java.util.concurrent.ThreadLocalRandom 으로 대체되었음\r\n\r\n### 선택하기 어렵다면 동기화하지 말고 대신 문서에 \"스레드 안전하지 않다\" 라고 명시하자!\r\n\r\n### 클래스 내부에서 동기화 하는 경우 다양한 기법\r\n- 클래스 내부에서 동기화하기로 했다면\r\n- 락 분할 (lock splitting)\r\n- 락 스트라이핑 (lock striping)\r\n- 비 차단 동시성 제어 (nonblocking concurrency control)\r\n- 등 다양한 기법을 동원해 동시성을 높여줄 수 있음\r\n- 위 기법들은 따로 공부하는 것을 추천\r\n\r\n### 여러 스레드가 호출할 가능성이 있는 메서드가 정적 필드를 수정한다면 그 필드를 사용하기 전에 반드시 동기화해야 함! (비결정적 행동도 용인하는 클래스라면 상관 없음)\r\n- 그런데 클라이언트가 여러 스레드로 복제돼 구동되는 상황이라면 다른 클라이언트에서 이 메서드를 호출하는 걸 막을 수 없으니 외부에서 동기화할 방법이 없음\r\n- 결과적으로 이 정적 필드가 심지어 private라도 서로 관련 없는 스레드들이 동시에 읽고 수정할 수 있게 됨\r\n- 사실상 전역변수와 같아짐\r\n- 아이템 78에서 generateSerialNumber 메서드에서 쓰인 nextSerialNumber 필드가 바로 이러한 사례\r\n\r\n## 정리\r\n- 교착 상태와 데이터 훼손을 피하려면 동기화 영역 안에서 외계인 메서드를 절대 호출하지 말자!\r\n- 일반화하자면 동기화 영역 안에서의 작업은 최소한으로 줄이자!\r\n- 가변 클래스를 설계할 때는 스스로 동기화해야 할지 고민하자!\r\n- 멀티코어 세상인 지금도 과도한 동기화를 피하는 게 과거 어느 때보다 중요!\r\n- 합당한 이유가 있을 때만 내부에서 동기화하고 동기화했는지 여부를 문서에 명확히 밝히자!\u003c/div\u003e","author":{"url":"https://github.com/JoisFe","@type":"Person","name":"JoisFe"},"datePublished":"2023-04-02T09:27:44.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/192/Effective-Java/issues/192"}