Merge pull request #350 from Flamme1004K/item79

[#79][2기] 과도한 동기화는 피하라.

11장/79_과도한 동기화는 피하라_김형준.md

@@ -0,0 +1,171 @@
+# Item79 과도한 동기화는 피하라
+
+ 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안 된다.
+
+ ### 여기서 제어란 ? 
+ - 재정의할 수 있는 메서드를 호출
+- 클라이언트가 넘겨준 함수 객체를 호출
+
+--> 이러한 동기화 메서나 및 동기화 블록에 대한 제어는 과도한 동기화를 일으킴.
+
+- 성능을 떨어트림.
+- 교착상태에 빠트림.
+- 예측할 수 없는 동작을 낳기도 한다.
+- 데이터를 훼손 할 수 있음.
+
+---
+    public class ObservableSet<E> Extends ForwardingSet<E> {
+		public ObservableSet(Set<E> set) {super(set);}
+		
+		public void addObserver(SetObserver<E> observer) {
+			synchronized(observer) {
+				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> sbserver : observers)
+				    observer.added(this, element);
+				}
+			}
+	    }
+	    
+	    @Override 
+	    public boolean add(E element) {
+		    boolean added = super.add(element);
+		    if (added)
+			    notifyElementAdded(element);
+			return added;
+		}
+		
+		@Override
+		public booleand addAll(Collection<? extends E> c) {
+			booleand result = false;
+			for (E element : c)
+				result = add(element);
+			return result;
+		}
+	}
+---
+
+1. 관찰자들은 addOverserver와 removeObserver 메서드를 호출해 구독을 신청하거나 해지한다.
+2. 두 경우 다음 콜백 인터페이스의 인스턴스를 메서드에 건넨다.
+
+---
+
+    @FuntionalInterface 
+    public interface SetObserver<E> {
+	    void added(ObservableSet<E> set, E element);
+    }
+
+해당 ObserverSet은  잘 작동할 것 같다고 한다.
+
+---
+
+    public static void main(String[] args) {
+	    ObservableSet<Integer> set = new ObservableSet<>(new HashSet<>());
+	    set.addObserver((s,e) -> System.out.println(e));
+	    for (int i = 0; i< 100; i++)
+		    set.add(i);
+    }
+
+여기서도 0~99까지 출력을 한다.
+
+---
+
+    set.addObserver(new SetObserver<>() {
+	    public void added(ObservableSet<Ineger> s, Integer e) {
+		    System.out.println(e);
+		    if (e == 23)
+			    s.removeObserver(this);
+	    }
+    }
+하지만 여기서 23이면 자기 자신을 제거하는 관찰자를 추가해 보자.
+어떻게 될까? 
+
+0~23까지 출력한 후 관찰자 자신을 구독해지한 다음 조용히 종료할 것이다라고 하지만,
+실제로 그렇지는 않고. 바로 ConcurrentModificationException을 던진다.
+왜그럴까? 그 이유는 리스트에서 원소를 제거하려 하는데,  이때 이 리스트를 순회하는 도중이라, 허용을 하지 않는 것이다.
+
+notifyElementAdded 메서드에서 수행하는 순회는 동기화 블록 안에 있으므로 동시 수정이 일어나지 않도록 보장하지만 정작 자신이 콜백을 거쳐 되돌아와 수정하는 것까지 막지는 못한다고 한다.
+
+---
+
+    set.addObserver(new SetObserver<> {
+	    public void added(ObservableSet<Integer> s, Integer e) {
+		    System.out.println(e);
+		    if (e == 23) {
+			    ExecutorService exec = Excutors.newSingleThreadExcutor();
+			    try (
+				    exec.submit(() -> s.removeObserver(this)).get();
+				} catch (ExcutionException | InterruptedException ex) {
+					throw new AssertionError(ex);
+				} finally {
+					exec.shutdown();
+				}
+		    }
+	    }
+    }
+
+해당 예제에서는 
+1. 백그라운드 스레드가 s.removeObserver를 호출하면 관찰자를 잠그려 시도하지만 락을 얻을 수 없다고 한다. 바로 메인 스레드가 이미 락을 쥐고 있기 때문이라고 한다. 
+2. 하지만 여기서, 그와 동시에 메인 스레드는 백그라운드 스레드가 관찰자를 제거하기만 기다리기 때문에 교착 상태가 일어난다고 한다.
+
+---
+
+어떻게 리팩토링을 해야할까?
+
+바로 
+
+    private void notifyElementAdded(E element) {
+		    List<SetObserver<E>> snapshot = null;
+		    
+		    synchronized(observers) {
+			    sanpShot new ArrayList<>(Observers);
+			}
+			
+			for (SetObserver<E> sbserver : observers)
+				    observer.added(this, element);
+			}
+	}
+
+동기화 블록 바깥으로 옮기면 된다고 한다. 이렇게 옮겨버리면, 락 없이도 안전하기 순회할 수 있다고 하며, 예외 발생과 교착상태 증상이 사라진다고 한다.
+
+
+
+# 어떻게 동기화를 해야하는 걸까?
+
+1. 동기화를 전혀 하지 말고, 그 클래스를 동시에 사용해야 하는 클래스가 외부에서 알아서 동기화하게 하자. 
+2. 동기화를 내부에서 수행해 스레드 안전한 클래스로 만들자. 
+
+ **첫번 째 방식**은 java.util(Vector와 HashTable을 제외) 택하였고, 
+ **두번 째 방식**은 Java.util.concurrent를 택하였다. 단, 두번 째 방식은 클라이언트가 외부에서 객체 전체에 락을 거는 것보다 동시성을 월등히 개선할 수 있을 때 선택해야한다.
+
+자바는 초창기에는 이 지침을 따르지 않았다고 한다.
+
+StringBuffer 인스턴스는 거의 항상 단일 쓰레드에서 쓰였음에도 내부적으로 동기화를 수행하였다. 이로 인해, 동기화를 하지 않는 StringBuilder가 만들어 졌다.
+
+비슷한 방법으로 java.util.Random은 동기화하지 않는 버전인 java.util.concurrent.ThreadLocalRandom으로 대체되었다.
+
+만약 두개가 힘들다면, 스레드 안전하지 않다고 명기하자.
+
+3.  여러 스레드가 호출할 가능성이 있는 메서드가 정적 필드를 수정한다면 그 필드를 사용하기 전에 반드시 동기화를 해야 한다.
+
+ 정적 필드가 심지어 pirvate라도 서로 관련 없는 스레드들이 동시에 읽고 수정할 수 있게 되면, 사실상 전역 변수와 같아지기 때문이다.
+
+## 결론
+
+ - 교착상태와 데이터 훼손을 피하려면 동기화 영역 안에서 외계인 메서드를 절대 클라이언트에게 양도하면 안된다.
+
+- 동기화 영역 안에서의 작업은 최소한으로 줄이자. 가변 클래스를 설계할 때는 스스로 동기화해야 할지 고민하자. 
+
+ - 멀티코어 세상인 지금은 과도한 동기화를 피하는 게 과거 어느 때보다 중요하다.
+
+- 합당한 이유가 있을 때만 내부에서 동기화하고, 동기화했는지 여부를 문서에 명확히 밝히자.