Skip to content

Latest commit

 

History

History
83 lines (67 loc) · 4.23 KB

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

File metadata and controls

83 lines (67 loc) · 4.23 KB
Raw

아이템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에서 내부 동기화를 생략했을 때

외부에서 사용할 수 있는 락을 제공하면?

    /**
     *  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공격을 막으려면 비공개 락 객체를 사용해야 한다.

비공개 락 객체?

  • //락 객체가 교체되는 걸 방지하기 위해 final, 외부에서 못보게 private
private final Object lock = new Object();

public void foo() {
  synchronized(lock) {
    ...
  }
}

  • 클라이언트가 객체의 동기화에 관여할 수 없다

  • 무조건적 스레드 안전 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 사용할 수 없다

  • 상속용으로 설계한 클래스에 특히 잘 맞는다.

    • 하위 클래스에서 기반 클래스의 락을 사용한다면, 서로가 서로를 훼방놓는 상태에 빠진다. 기반 클래스의 락에 애초에 접근할 수 없으므로 상속용으로 좋다.

결론

모든 클래스는 스레드 안정성 정보를 명확하게 문서화해야 한다.