DEV ℧ Developer Diary

[EffectiveJava] item82 - 스레드 안전성 수준을 문서화 하라

02 Aug 2023

API문서에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다.
만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나 지나치게 한 상태이며, 두 경우 모두 심각한 오류로 이어질 수 있다.

스레드 안정성 문서화

API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 이야기가 있다.

이말은 틀렸다. 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다. 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다.

멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안정설 수준을 명확히 명시해야 한다.

스레드 안정설 수준

다음 목록은 스레드 안전성이 높은 순으로 나열한 것이다.

불변 (immutable)

이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요없다.

예시) String, Long, BigInteger

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

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

예시) AtomicLong, ConcurrentHashMap

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

무조건적 스레드 안전과 같으나. 일부 메서드는 동시에 사용하려면 외부 동기화가 필요하다.

예시) Collections.synchronized 래퍼 메서드가 반환한 Collection

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

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

예시) ArrayList, HashMap과 같은 기본 Collection

스레드 적대적 (thread-hostile)

이 클래스는 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하기 않다. 이 수준의 클래스는 일반적으로 정적데이터를 아무 동기화 없이 수정한다.

스레드 안정설 애너테이션

위의 분류는 스레드 적대적을 제외하고는 각각 아래의 애너테이션과 매치 할 수 있다.

  • @Immutable: 불변
  • @ThreadSafe: 무조건적 스레드 안전, 조건부 스레드 안전
  • @NotThreadSafe: 스레드 안전하지 않음

문서화의 주의할점

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

  • 어떤 순서로 호출할때 외부 동기화가 필요한지 문서화 해야한다.
  • 그 순서로 호출하려면 어떤 락 혹은 락들을 얻어야 하는지 알려줘야 한다.

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(); }

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

열거 타입은 굳이 불변이라고 쓰지 않아도 된다. 반환 타입만으로는 명확히 알 수 없는 정적 팩터리라면 자신이 반환하는 객체의 스레드 안정성을 반드시 문서화 해야한다.

비공개 락 객체 관용구

클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메서드 호출은 원자적으로 수행할 수 있다. 하지만 이 유연성에는 대가가 따른다.

내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수없게 된다.

잘못하면 클라이언트가 공개된 락을 오래쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 수행할 수도 있다.

서비스 거부 공격을 막으려면 synchronized 메서드 대신 비공개 락 객체를 사용해야 한다.

비공개 락 객체 관용구

private final Object lock = new Object();

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

비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다.

상속용 클래스의 비공개 락 객체

또한 비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다.

만약 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면, 하위 클래스는 아주 쉽게, 의도치 않게 기반 클래스의 동작을 방해할 수 있기 때문이다.

그래서 하위 클래스와 기반 클래스는 ‘서로가 서로를 훼방놓는’ 상태에 빠진다.

Related posts