스레드 문서화의 필요성
한 메서드를 여러 스레드가 호출했을 때 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과도 같다. API 문서에서 언급이 없다면 사용자는 나름의 가정을 해야만 하고, 지나치게 동기화를 하거나 충분히 하지 못해 심각한 오류로 이어질 수 있다.
API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 이야기를 들었을지 모르겠다. 하지만 이 이야기는 몇 가지 면에서 틀렸다. 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자는 포함되지 않는다. 메서드 선언에 synchronized 한정자를 선언할지 말지는 구현 이슈일 뿐 API에 속하지 않기 때문이다. 따라서 이것만으로는 그 메서드가 스레드 안전하다고 믿기 어렵다.
스레드 안정성에도 수준이 나뉜다. 멀티스레드 환경에서도 API를 안전하게 사용하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야만 한다.
- 불변(immutable)
- 이 클래스의 인스턴스는 상수와도 같다. 따라서 외부 동기화도 필요 없다. String, BigInteger, Long이 대표적이다.
- 무조건적 스레드 안전(unconditionally thread-safe)
- 이 클래스의 인스턴스는 수정될 수 있지만, 내부에서 충실히 동기화해 별도 외부 동기화 없이 동시에 사용해도 안전하다. AtomicLong, ConcurrentHashMap이 여기에 속한다.
- 조건부 스레드 안전(conditionally thread-safe)
- 무조건적 스레드 안전과 같으나, 일부 스레드는 외부 동기화가 필요하다. Collections.synchronized 래퍼 메서드가 반환한 컬렉션들이 여기 속한다.
- 스레드 안전하지 않음(not thread-safe)
- 이 클래스의 인스턴스는 수정될 수 있다. 동시에 사용하려면 각각의 메서드 호출을 클라이언트가 선택한 외부 동기화 매커니즘으로 감싸야만 한다. ArrayList, HashMap 같은 기본 컬렉션들이 여기 속한다.
- 스레드 적대적(thread-hostile)
- 이 클래스는 모든 메서드 호출을 외부 동기화로 감싸도 멀티 스레드 환경에서 안전하지 않다. 이 수준에서는 정적 데이터를 아무 동기화 없이 수정한다.
조건부 스레드 안전 클래스의 경우 주의해서 문서화해야 한다. 어떤 순서로 호출할 때 외부 동기화가 필요한지, 어떤 락들을 얻어야 하는지 알려줘야 한다.
클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재하지만, 독특한 특성의 메서드라면 해당 메서드의 주석에 기재하자. 열거 타입은 굳이 불변이라고 쓰지 않아도 된다. 반환 타입만으로 명확히 알 수 없는 정적 팩터리라면 자신이 반환하는 객체의 스레드 안전성을 반드시 문서화 해야 한다.
비공개 락 객체
클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트는 메서드 호출을 원자적으로 수행할 수 있다. 하지만 이 유연성에는 대가가 따른다. 내부에서 처리하는 ConcurrentHashMap과 같은 고성능의 동시성 제어 매커니즘을 가진 동시성 컬렉션과는 혼용할 수 없게 된다. 또 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 수행할 수도 있다.
서비스 거부 공격을 막으려면 공개된 락(synchronized 메서드 포함) 대신 비공개 락 객체를 사용해야 한다. 비공개 락 객체는 바깥에서 볼 수 없으니 클라이언트가 그 객체의 동기화에 관여할 수 없다. 다만 비공개 락 객체는 무조건적 스레드 안전한 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지 알려줘야 하기 때문이다. 비공개 락 객체는 특히 상속용으로 설계한 클래스에 잘 맞는다.
