[아이템 82] 스레드 안전성 수준을 문서화하라

[meloncha]

스레드 안전성 수준

• API 문서에 synchronized 유무로 스레드 안전하다고 믿을 수 없다
• 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다

불변 (immutable)

• 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요없다
• String, Long, BigInteger
• @Immutable

무조건적 스레드 안전 (unconditionally thread-safe)

• 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화없이 동시에 사용해도 안전하다

• AtomicLong, ConcurrentHashMap

• @ThreadSafe

• Atomic 의 경우 CAS(Compare And Swap)방식으로 동기화 문제를 해결

  CAS : 변수의 값을 변경하기 전에 기존에 가지고 있던 값이 내가 예상하던 값과 같을 경우에만 새로운 값으로 할당하는 방법

  public class AtomicExample {
      int val;
      
      public boolean compareAndSwap(int oldVal, int newVal) {
          if(val == oldVal) {
              val = newVal;
              return true;
          } else {
              return false;
          }
      }
  }

• ConcurrentHashMap 의 경우

  • 빈 해시 버킷에 노드를 삽입하는 경우 Compare and Swap 을 사용하여 새로운 노드를 해시 버킷에 삽입한다

- 이미 노드가 존재하는 경우에는 synchronized 를 이용해 하나의 스레드만 접근할 수 있도록 제어한다

조건부 스레드 안전 (conditionally thread-safe)

• 무조건적 스레드 안전과 같으나, 일부 메서드는 동시에 사용하려면 외부 동기화가 필요하다
• Collections.synchronized 래퍼 메서드가 반환한 컬렉션들
• 사용시에 동기화 해야한다
• @ThreadSafe

List list = Collections.synchronizedList(new ArrayList<>());

//...

//사용시에 동기화 시켜 줍니다.
synchronized (list) {
	list.add(...);
}

스레드 안전하지 않음 (not thread-safe)

• 이 클래스의 인스턴스는 수정될 수 있다.
• 동시에 사용하려면 각각의 메서드 호출을 클라이언트가 선택한 외부 동기화 메커니즘으로 감싸야 한다
• ArrayList, HashMap 등
• @NotThreadSafe

// not thread-safe
public class Test {
    private Set<String> set = new TreeSet<>();

    public void add(String s) {
        set.add(s);
    }
}

스레드 적대적 (thread-hostile)

• 이 클래스는 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다
• 이 수준의 클래스는 일반적으로 정적 데이터를 아무 동기화 없이 수정한다
• 스레드 적대적으로 밝혀진 클래스나 메서드는 문제를 고쳐 재배포하거나 사용 자제 API로 지정한다

// thread-hostile
private static Set<String> set = new TreeSet<>();

스레드 안전성 주석

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

Lock 제공

• 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메서드 호출을 원자적으로 수행할 수 있다
• 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용이 안된다
  • ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 ㅇ못한다
• 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 수행할 수 있다
• dos 공격을 막으려면 synchronized 메서드 대신 비공개 락 객체를 사용해야 한다

// 비공개 락 객체 final 선언 -> 락 객체가 교체되는 일을 예방
private final Object lock = new Object();

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

• 비공개 락 객체는 클래스 바깥에서는 볼 수 없으니 클라이언트가 그 객체의 동기화에 관여할 수 없다
• 비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다
• 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로 이 관용구를 사용할 수 없다

정리

• 모든 클래스가 자신의 스레드 안전성 정보를 명확히 문서화해야 한다
• 정확한 언어로 명확히 설명하거나 스레드 안전성 애너테이션을 사용할 수 있다
• synchronized 는 문서화와 관련이 없다
• 조건부 스레드 안전 클래스는 메서드를 어떤 순서로 호출할 때 외부 동기화가 요구되고, 그때 어떤 락을 얻어야 하는지도 알려줘야 한다
• 무조건적 스레드 안전 클래스를 작성할 때는 synchronized 메서드가 아닌 비공개 락 객체를 사용하자