[#82][A팀] 스레드 안전성 수준을 문서화하라

[#82][A팀] 스레드 안전성 수준을 문서화하라

11장/82_스레드_안전성_수준을_문서화하라_황준호.md

@@ -0,0 +1,83 @@
+### 아이템82. 스레드 안전성 수준을 문서화하라
+
+API 문서에 스레드 안정성에 대한 내용이 없으면 사용자는 동기화를 부족하게 하거나 과하게 하는 경우가 생길 수 있다.
+
+멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안정성 수준을 명시해야 한다.
+
+다음은 스레드 안정성 수준이 높은 순으로 나열한 것이다.
+
+1. 불변 (immutable)
+   - 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화가 필요없다.
+   - 예) String, Long, BigInteger 등..
+2. 무조건적 스레드 안전 (unconditionally thread-safe)
+   - 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화가 필요없다.
+   - synchronized 메서드가 아닌 비공개 락 객체를 사용한다.
+   - 예) AtomicLong, ConcurrentHashMap
+3. 조건부 스레드 안전 (conditionally thread-safe)
+   - 무조건적 스레드 안전과 같으나 일부 메서드는 동시에 사용하려면 외부 동기화가 필요하다
+   - 그래서 주의해서 문서화해야 한다.
+     - 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그 순서로 호출하려면 어떤 락을 얻어야 하는지 등
+     - 클래스의 스레드 안정성은 보통 클래스의 문서화 주석에 기재하지만, 독특한 메서드라면 해당 메서드에 문서화하자.
+   - 예) Collections.synchronizedMap, Collections.synchronizedSet 등등이 반환한 컬렉션들
+4. 스레드 안전하지 않음 (not thread-safe)
+   - 클래스의 인스턴스가 수정될 수 있다
+   - 동시에 사용하려면 클라이언트가 별도의 동기화를 수행해야 한다.
+   - 예) ArrayList, HashMap 등의 기본 컬렉션
+5. 스레드 적대적 (thread-hostile)
+   - 이 클래스는 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다.
+   - 고의로 만드는 사람은 없지만 동시성을 고려하지 않고 작성하다보면 우연히 만들어질 수 있다.
+   - 예) generateSerialNumber에서 내부 동기화를 생략했을 때
+
+외부에서 사용할 수 있는 락을 제공하면?
+
+```java
+    /**
+     *  synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵의 락으로 사용해 수동으로 동기화하라.
+     * <pre>
+     *  Map m = Collections.synchronizedMap(new HashMap());
+     *      ...
+     *  Set s = m.keySet();  // 동기화 블록 밖에 있어도 된다.
+     *      ...
+     *  synchronized (m) {  // s가 아닌 m을 사용해 동기화해야 한다.
+     *      Iterator i = s.iterator(); // 동기화 블록 안에 있어야 한다.
+     *      while (i.hasNext())
+     *          foo(i.next());
+     *  }
+     * </pre>
+     * 이대로 하지 않으면 동작을 예측할 수 없다.
+     */
+    public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
+        return new SynchronizedMap<>(m);
+    }
+```
+
+- 장점 : 클라이언트에서 일련의 메서드를 원자적으로 수행할 수 있다.
+- 단점
+  - 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없다 -> 동시성 컬렉션과는 함께 사용할 수 없다
+  - 클라이언트가 DOS공격(공개된 락을 오래 쥐고 놓지 않음)을 수행할 수도 있다.
+  - DOS공격을 막으려면 비공개 락 객체를 사용해야 한다.
+
+비공개 락 객체?
+
+- ```java
+  //락 객체가 교체되는 걸 방지하기 위해 final, 외부에서 못보게 private
+  private final Object lock = new Object();
+
+  public void foo() {
+    synchronized(lock) {
+      ...
+    }
+  }
+  ```
+
+- 클라이언트가 객체의 동기화에 관여할 수 없다
+
+- 무조건적 스레드 안전 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 사용할 수 없다
+
+- 상속용으로 설계한 클래스에 특히 잘 맞는다.
+
+  - 하위 클래스에서 기반 클래스의 락을 사용한다면, 서로가 서로를 훼방놓는 상태에 빠진다. 기반 클래스의 락에 애초에 접근할 수 없으므로 상속용으로 좋다.
+
+#### 결론
+
+모든 클래스는 스레드 안정성 정보를 명확하게 문서화해야 한다.