[Effective-Java] Item 82. 스레드 안전성 수준을 문서화하라

한 메소드를 여러 스레드가 동시 호출할 때 어떻게 동작하냐는 중요하다. API 문서에 아무 언급이 없으면 클래스 사용자는 여러가지 가정을 해야한다. 가정이 틀릴 경우 동기화를 충분히 하지 못하거나 지나치게 하는 상황을 초래할 수 있고 두 경우 다 심각한 오류로 이어질 수 있다.

 

API 문서의 synchronized 한정자

---

API 문서에 synchronized 한정자가 보이는 메소드는 스레드 안전하다고 100% 확신할 수 없다. 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다. 메소드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않기 떄문이다. synchronized 유무로 스레드 안전성을 알수있다는 것은 모 아니면 도라는 위험한 발상이다. 

 

따라서 멀티스레드 환경에서도 API를 안전하게 사용하려면 클래스가 지원하는 스레드 안정성 수준을 정확히 명시하자.

 

스레드 안전성 수준

---

불변(immutable) - @Immutable

클래스의 인스턴스가 마치 상수와 같아 외부 동기화가 필요없는 경우

ex) String, Long, BigInteger

 

무조건적 스레드 안전(unconditionaly thread-safe) - @ThreadSafe

클래스의 인스턴스는 수정될 수 있으나, 내부에서 동기화를 충실히 하여 별도의 외부 동기화 없이 동시에 사용 가능한 경우

ex) AtomicLong, ConcurrentHashMap

 

조건적 스레드 안전(conditionally thread-safe) - @ThreadSafe

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

ex) Collections.synchronized 래퍼 메소드: 반환된 컬렉션들은 내부적으로 동기화 블록을 갖지만, 반복자는 외부에서 동기화해야한다. 

 

Collections.synchronizedList 예시: 다양한 메소드들은 mutex를 synchronized 블록에서 사용하지만, iterator는 동기화하지 않았다.

 

래퍼 메소드를 보면 iterator 뿐만 아니라 Spliterator나 Stream에도 동기화가 필요하다고 나와있다. 동기화 사용법도 주석으로 달려있다.

 

조건부 스레드 안전한 클래스는 주의해서 문서화해야 한다. 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그 순서로 호출하려면 어떤 락 혹은 락들을 얻어야 하는지 알려줘야 하고, 일반적으로 인스턴스 자체를 락으로 얻지만 예외는 있다.

 

Collections.synchronizedMap의 API 문서를 보자.

 

 

이 맵의 keyset은 synchronized block에서 사용할 필요가 업고 keyset을 꺼낸 Map을 동기화 하라고 나온다. keyset의 iterator를 돌릴건데 왜 Map을 동기화 하란걸까? 우선 synchronizedMap의 keyset 메소드를 한 번 보자.

 

 

keySet이 존재하지 않는다면 SynchronizedSet 구현체를 넣는 것을 알 수 있다. 이 때, 락 객체는 SynchronizedMap과 같은 mutex를 공유한다. 그리고 SynchronizedMap을 생성할 때 매개변수로 넣었던 Map의 keyset을 가져온다. SynchronizedSet 클래스를 보자. 

 

 

SynchronizedSet의 기본적인 메소드는 SynchronizedCollection을 상속했고, 이 클래스로 가보면 모든 Collection의 행위를 매개변수로 넘어온 Collection의 메소드를 실행하는 래퍼클래스 형식으로 작성되어있다. KeySet은 add 메소드를 구현하지 않았으니 UnsupportOperationException을 던진다. 삭제는 Synchronized(Map,Set) 둘 다 되지만, 추가는 SynchronizedMap만 가능하다. 만약 SynchronizedSet만 동기화를 해버리면, 순회 중에 Map에 값을 추가하는게 가능해진다. 따라서 Map을 동기화해야 올바르게 동기화가 되었다고 할 수 있는 것이다.

 

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

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

 

스레드 적대적(thread-hostile)

이 클래스는 모든 메소드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않고 일반적으로 정적 데이터를 아무 동기화 없이 수정한다. 고의로 만들 일은 없겠지만 동시성을 고려하지 않고 작성하다 보면 우연히 만들어질 수 있고 스레드 적대적으로 밝혀진 클래스나 메소드는 일반적으로 문제를 고쳐 재배포하거나 사용 자제(deprecated) API로 지정한다. ex) 아이템78의 generateSerialNumber

 

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

비공개 Lock 객체 사용

---

클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메소드 호출을 원자적으로 수행할 수 있다. 하지만 이러한 유연성은 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없는 단점이 있다. 그래서 ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 못하고, 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 수행할 수도 있다.

 

서비스 거부 공격을 막으려면 공개된 락과 마찬가지인 synchronized 메소드 대신 비공개 락 객체를 사용하자. 즉, 락 객체를 동기화 대상 객체 안으로 캡슐화하는 것.

 

private final Object lock = new Object();

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

 

비공개 락 객체는 클래스 외부에서 못 보니 클라이언트가 그 객체의 동기화에 관여할 수 없다. 그리고 lock 필드는 final로 선언하자. 우연히라도 락 객체가 교체되는 일을 예방한다. 락 필드 변경 가능성을 최소화한 것으로 일반적인 감시 락이든 java.util.concurrent.locks 패키지에서 가져온 락이든 마찬가지다. 이 패키지의 락들의 예시는 여기를 참고했다.

 

비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있고, 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지 클라이언트에게 알려줘야 해서 이 관용구를 사용할 수 없다. 

 

뿐만아니라, 상속용 클래스에도 잘 맞는다. 상속용 클래스에서 자신의 인스턴스를 락으로 가진다면(synchronized 메소드나 블록을 통해) 하위 클래스는 의도치 않게 기반 클래스의 동작을 방해할 수 있다. 같은 락을 다른 목적으로 사용하게 되어 하위 클래스와 기반 클래스는 서로서로 훼방을 놓는 상태에 빠지고 이는 종종 Thread 클래스에서 나타나곤 하는 문제다.

 

부모 클래스에서 synchronized 메소드나 블록을 사용하고 오래동안 lock을 쥐고있다고 가정해보자. 자식 클래스에서 이 메소드를 super를 통해 호출한다면 자식 클래스에 lock이 생긴다. 자식 클래스에서 다른 synchronized 메소드나 블록을 사용하려 하면 lock이 걸려있기 때문에 당장 사용할 수 없는 문제가 발생한다. 하지만 비공개 락 객체 관용구를 사용한다면 이 문제에서 자유롭다.

 

정리

---

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

 

 

* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.