아이템 82. 스레드 안전성 수준을 문서화하라. - ksw6169/effective-java GitHub Wiki

스레드 안전성 수준을 문서화하라.

  • 스레드 안전성 수준을 문서화하지 않으면 클라이언트는 동기화를 충분히 하지 못하거나 지나치게 한 상태일 것이며 두 경우 모두 심각한 오류로 이어질 수 있다.
  • synchronized 한정자가 선언되었다고 해서 그 메소드가 스레드 안전하다고 믿기 어렵다.

스레드 안전성의 수준

  • 스레드 안전성에도 수준이 나뉜다.
  • 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.
  • 다음 목록은 스레드 안전성 수준이 높은 순으로 나열한 것이다.
1. 불변(immutable)
- 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요 없다.
- String, Long, BigInteger가 대표적이다.

2. 무조건적 스레드 안전(unconditionally thread-safe)
- 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 동시에 사용해도 안전하다.
- AtomicLong, ConcurrentHashMap이 여기에 속한다.

3. 조건부 스레드 안전(conditionally thread-safe)
- 무조건적 스레드 안전과 같으나, 일부 메소드는 동시에 사용하려면 외부 동기화가 필요하다.
- Collections.synchronized 래퍼 메소드가 반환한 컬렉션들이 여기 속한다.
  (이 컬렉션들이 반환한 반복자는 외부에서 동기화해야 한다.)

4. 스레드 안전하지 않음(not thread-safe)
- 이 클래스의 인스턴스는 수정될 수 있다.
- 동시에 사용하려면 각각의 메소드 호출을 클라이언트가 선택한 외부 동기화 메커니즘으로 감싸야 한다.
- ArrayList, HashMap 같은 기본 컬렉션이 여기 속한다.

5. 스레드 적대적(thread-hostile)
- 이 클래스는 모든 메소드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다.
- 이 수준의 클래스는 일반적으로 정적 데이터를 아무 동기화 없이 수정한다.
- 이런 클래스를 고의로 만드는 사람은 없겠지만, 동시성을 고려하지 않고 작성하다 보면 우연히 만들어질 수 있다.
- 스레드 적대적으로 밝혀진 클래스나 메소드는 일반적으로 문제를 고쳐 재배포하거나 deprecated API로 지정한다.
- 아이템 78의 generateSerialNumber 메소드에서 내부 동기화를 생략하면 스레드 적대적이게 된다.
  • 이 분류는 스레드 적대적만 빼면 스레드 안전성 어노테이션인 @Immutable, @ThreadSafe, @NotThreadSafe 와 대략 일치한다.
    (앞 분류의 무조건적 스레드 안전과 조건부 스레드 안전은 모두 @ThreadSafe 어노테이션 밑에 속한다.)

스레드 안전성 수준의 문서화 시 주의사항

1. 조건부 스레드 안전한 클래스는 주의해서 문서화해야 한다.

  • 조건부 스레드 안전한 클래스는 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그리고 그 순서로 호출하려면 어떤 락을 얻어야 하는지 알려줘야 한다.
  • 예를 들어 Collections.synchronizedMap 의 API 문서에는 다음과 같이 써 있다.
/*
 * synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 
 * 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.
 */
Map<K, V> m = Collections.synchronizedMap(new HashMap<>());
Set<K> s = m.keySet();  // 동기화 블록 밖에 있어도 된다.

synchronized(m) {    // s가 아닌 m을 사용해 동기화해야 한다.
    for (K key : s)
        key.f();
}

// 이대로 따르지 않으면 동작을 예측할 수 없다.

2. 기타

  • 클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재하지만 독특한 특성의 메소드라면 해당 메소드의 주석에 기재하도록 하자.
  • 열거 타입은 굳이 불변이라고 쓰지 않아도 된다.
  • 반환 타입만으로는 명확히 알 수 없는 정적 팩토리라면 자신이 반환하는 객체의 스레드 안전성을 반드시 문서화해야 한다. (Collections.synchronizedMap 이 좋은 예다.)

무조건적 스레드 안전 클래스에서는 synchronized 대신 비공개 락 객체를 사용하라.

  • 클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메소드 호출을 원자적으로 수행할 수 있다. 하지만 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없게 된다. 그래서 ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 못한다.
  • 또한 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 수행할 수도 있다. 이 같은 서비스 거부 공격을 막으려면 synchronized 메소드(이 역시 공개된 락이나 마찬가지다) 대신 비공개 락 객체를 사용해야 한다.
// 비공개 락 객체 관용구 - 서비스 거부 공격을 막아준다.
private final Object lock = new Object();

public void foo() {
    synchronized(lock) {
        ...
    }
}
  • 비공개 락 객체는 클래스 바깥에서는 볼 수 없으니 클라이언트가 그 객체의 동기화에 관여할 수 없다.
  • 비공개 락 객체 관용구는 무조건 스레드 안전 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로 이 관용구를 사용할 수 없다.
  • 비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다. 만약 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면 하위 클래스에서 의도치 않게 동기화 메커니즘을 깨뜨릴 수 있으므로 상속용 클래스에서는 비공개 락 객체 사용을 고려하자.

앞의 코드에서 lock 필드를 final로 선언한 이유

락이 교체되면 끔찍한 결과로 이어진다. 따라서 우연히라도 락 객체가 교체되는 일을 방지하기 위해 락 필드는 항상 final로 선언하라.


핵심 정리

  • 모든 클래스가 자신의 스레드 안전성 정보를 명확히 문서화해야 한다.
  • 이 때 정확한 언어로 명확히 설명하거나, 스레드 안전성 어노테이션을 사용할 수도 있다.
  • 조건부 스레드 안전 클래스는 메소드를 어떤 순서로 호출할 때 외부 동기화가 요구되고, 그때 어떤 락을 얻어야 하는지도 알려줘야 한다.
  • 무조건적 스레드 안전 클래스를 작성할 때는 synchronized 메소드가 아닌 비공개 락 객체를 사용하자. 이렇게 해야 클라이언트나 하위 클래스에서 동기화 메커니즘을 깨뜨리는 걸 예방할 수 있고, 필요하다면 다음에 더 정교한 동시성을 제어 메커니즘으로 재구현할 여지가 생긴다.

참고 자료

  • Effective Java 3/E
⚠️ **GitHub.com Fallback** ⚠️