들어가며

한 메소드가 여러 스레드를 동시에 호출할 때 그 메소드가 어떻게 동작하느냐는 중요하다. API문서에 아무런 언급도 없다면 클라이언트가 동기화를 충분히 하지 못하거나 과하게 시도하는 문제가 생길 수 있다. 멀티스레드 환경에서 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안정성 수준을 정확히 명시해야 한다.

• 불변
  • 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화가 필요없다.
• 무조건적 스레드 안전
  • 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 동시에 사용해도 안전하다.
• 조건부 스레드 안전
  • 무조건적 스레드 안전과 같으나 일부 메소드는 동시에 사용하려면 외부 동기화가 필요하다.
• 스레드 안전하지 않음
  • 이 클래스의 인스턴스는 수정될 수 있다. 동시에 사용하려면 각각의 메소드 호출을 클라이언트가 선택한 외부 동기화 메커니즘으로 감싸야 한다.
• 스레드 적대적
  • 이 클래스는 모든 메소드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다. 이 수준의 클래스는 일반적으로 정적 데이터를 아무 동기화 없이 수정한다.

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

* <pre>
*  Map m = Collections.synchronizedMap(new HashMap());
*      ...
*  Set s = m.keySet();  // Needn't be in synchronized block
*      ...
*  synchronized (m) {  // Synchronizing on m, not s!
*      Iterator i = s.iterator(); // Must be in synchronized block
*      while (i.hasNext())
*          foo(i.next());
*  }
* </pre>

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

클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메소드 호출을 원자적으로 수행할 수 있다. 하지만 이 유연성에는 대가가 따른다. 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없게 된다. 또한 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부공격을 수행할 수도 있다. 이를 막으려면 비공개 락 객체를 사용해야한다.

비공개 락 객체는 무조건적 스레드 안전 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 사용할 수 있다. 비공개 락 객체는 상속용으로 설계한 클래스에도 잘 맞는다. 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면 하위 클래스는 아주 쉽고 의도치 않게 기반 클래스의 동작을 방해할 수 있다. 그 역도 성립한다.