[Effective Java] Item82. 스레드 안전성 수준을 문서화하라!

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

Intro

• 한 메서드를 여러 스레드가 동시 호출할 때 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다.
• API 문서에서 아무런 언급이 없다면 클래스 사용자는 나름의 가정을 해야 하고, 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나, 지나치게 한 상태일 것이다. 두 경우 모두 심각한 오류로 이어질 수 있다.
• API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다고 생각할 수 있지만, 그건 틀린 생각이다.
  • 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다. 따라서 이것만으로는 그 메서드가 스레드 안전하다고 믿기 어렵다.
• 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로 지정한다.

스레드 안전성 애너테이션

• @Immutable
• @ThreadSafe
  • 무조건적 스레드 안전, 조건부 스레드 안전은 모두 여기에 속한다.
• @NotThreadSafe

스레드 안전성 수준 문서화

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

  • 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그리고 그 순서로 호출하면 어떤 락 혹은 (드물게) 락들을 얻어야 하는지 알려줘야 한다.

  • 일반적으로 인스턴스 자체를 락으로 얻지만 예외도 있다.

  • 예외는 예를 들어 Collections.synchronizedMap이 있고, synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화해야 한다.

    // Collections.synchronizedMap API 예시
    synchornizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.
        
    Map<K, V> m = Collections.synchronizedMap(new HashMap<>());
    Set<K> s = m.keySet(); // 동기화 불록 밖에 있어도 된다.
        
    synchronized(m) {  // s가 아닌 m을 사용해 동기화 해야한다!
    	for (K key : s)
    		key.f();
    }
    

• 클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재한다. 독특한 특성의 메서드라면 별도로 해당 메서드의 주석에 기재하도록 하자.

• 열거 타입은 굳이 불변이라고 쓰지 않아도 된다.

• 반환 타입만으로는 명확히 알 수 없는 정적 팩터리라면 자신이 반환하는 객체의 스레드 안전성을 반드시 문서화해야 한다.

공개 락

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

비공개 락

• 비공개 락 객체의 관용구다. 서비스 거부 공격을 막아준다.

private final Object lock = new Object();

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

• 비공개 락 객체는 클래스 바깥에서는 볼 수 없다. 그러니 클라이언트가 그 객체의 동기화에 관여할 수 없다.
  • 사실 상 락 객체를 동기화 대상 객체 안으로 캡슐화한 것이라 볼 수 있다.
• 비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다.
  • 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지 알려주어야 한다. 그러니 이 관용구 사용은 못한다.
• 비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다.
  • 상속용 클래스에서 자신의 인스턴스를 락으로 사용하게 되면, 사위 클래스는 아주 쉽고, 의도치 않았더라도 기반 클래스의 동작을 방해할 수 있음.

핵심 정리

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