Item 82. 스레드 안전성 수준을 문서화하라

[yejin9858]

한 메서드를 여러 스레드가 동시에 호출할 때,

“메서드가 어떻게 동작하느냐” → 해당 클래스 - 이를 사용하는 클라이언트 사이의 중요한 계약

API 문서에서 아무런 언급이 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다.

만약 그 가정이 틀리면 ,

-> 클라이언트 프로그램은 동기화를 충분히 못했음(Item 78) or 지나치게 함(Item 79)

⇒ 심각한 오류

다수의 스레드가 같은 자원에 접근하고 이 자원에 쓰기 작업을 수행할 때 경합 조건이 발생하는데, 쓰레드들이 어떤 객체의 상태를 변경할 수 없도록 함으로써 이 객체에게 불변성을 부여할 수 있고 이럴 때 이 객체는 쓰레드 안전하다

“API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다”는 틀린 문장이다.

• 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다.
  • 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않기 때문
  • 따라서 API 문서만 봐서는 알 수 없다.

• 스레드 안전성은 모 아니면 도가 아니다.

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

  • 스레드 안전성 수준

    스레드 안전성이 높은 순으로 나열했다. 일반적인 경우를 포괄한다.

    • 불변
      • 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요 없다.
      • ex) String, Long, BigInteger
    • 무조건적 스레드 안전
      • 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 동시에 사용해도 안전하다.
      • ex) AtomicLong, ConcurrentHashMap
    • 조건부 스레드 안전
      • 무조건적 스레드 안전과 같으나, 일부 메서드는 동시에 사용하려면 외부 동기화가 필요하다.
      • ex) Collections.synchronized
    • 스레드 안전하지 않음
      • 이 클래스의 인스턴스는 수정할 수 있다.
      • 동시에 사용하려면 각각의 메서드 호출을 클라이언트가 선택한 외부 동기화 매커니즘으로 감싸야한다.
      • ex) ArrayList, HashMap
    • 스레드 적대적
      • 이 클래스는 모든 메서드 호출을 외부동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다. 이 수준의 클래스는 일반적으로 정적 데이터를 아무 동기화 없이 수정한다.
      • 이런 클래스를 고의로 만드는 사람은 없겠지만, 동시성을 고려하지 않고 작성하다 보면 우연히 만들어질 수 있다. 스레드 적대적으로 밝혀진 클래스나 메서드는 일반적으로 문제를 고쳐 재배포하거나 사용 자제(deprecated) API로 지정한다.
      • ex) Item 78의 generateSerialNumber 메서드에서 내부 동기화를 생략하면 스레드 적대적이게 된다.

    스레드 적대적을 제외하고, “자바 병렬 프로그래밍” 부록 A의 스레드 안전성 애너테이션(@Immutable, @ThreadSafe, @NotThreadSafe)과 일치하는 분류이다.

    앞 분류의 무조건적 스레드 안전과 조건부 스레드 안전은 모두 @ThreadSafe 애노테이션 밑에 속한다.

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

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

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

    • ex) Collections.synchronizedMap

      synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.
      
      Map<K, V> m = Collections.synchronizedMap(new HashMap<>());
      Set<K> s = m.keySet();
      
      synchronized(m) {
          for (K key : s) key.f();
      }
      
      이대로 따르지 않으면 동작을 예측할 수 없다.

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

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

    • 내부에서 처리하는 ConcurrentHashMap같은 고성능 동시성 제어 메커니즘과 혼용할 수 없게 됨

    • 또한 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격을 수행할 수 도 있다.

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

      private final Object lock = new Object();
      
      public void foo(){
        synchronizned(lock) {
        }
      }

      • 비공개 락 개체는 클래스 바깥에서는 볼 수 없으니 클라이언트가 그 객체의 동기화에 관여할 수 없다. 사실 Item 15(클래스와 멤버의 접근 권한을 최소화하라) 의 조언을 따라 락 객체를 동기화할 대상 객체 안으로 캡슐화한것이다.
      • 락 필드는 항상 final로 선언하라
        • 우연히라도 락 객체가 교체되는 일을 예방해준다. 락이 교체되면 끔찍한 결과로 이어진다.(Item 78)
        • Item 17(변경 가능성을 최소화하라) 의 조언을 따라 다시 한번 락 필드의 변경 가능성을 최소화한것이다.
        • 일반적인 감시 락이든, java,util,concurrent.locks 패키지에서 가져온 락이든 마찬가지다.
      • 비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다.
        • 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로 이 관용구를 사용할 수 없다.
        • 비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다.
          • 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면, 하위 클래스는 기반 클래스의 동작을 방해할 수 있다.
          • 같은 락을 다른 목적으로 사용하게 되어 하위 클래스와 기반 클래스는 서로가 서로를 훼방놓는 상태에 빠질 수 있다.

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