요약
•
스레드 안전 수준을 문서화하자.
•
가급적 공개 락보다 비공개 락을 사용하자.
스레드 안전 수준
•
불변(immutable)
◦
클래스의 인스턴스가 상수처럼 동작해서, 외부 동기화가 전혀 필요 없는 상태
◦
String, Long, BigInteger 등과 같은 클래스가 여기에 해당된다.
◦
@Immutable
•
무조건적 스레드 안전(unconditionally thread-safe)
◦
클래스의 인스턴스가 수정될 수는 있지만, 내부에서 동기화 처리가 충분히 되어있어 별도의 외부 동기화 없이도 스레드 안전하게 사용 가능한 상태
◦
AtomicLong, ConcurrentHashMap이 여기에 속한다.
◦
@ThreadSafe
•
조건부 스레드 안전(conditionallly thread-safe)
◦
클래스의 인스턴스가 수정될 수 있고 내부 동기화가 되어있지만, 일부 메서드를 동시에 사용하려면 외부 동기화가 필요한 상태
◦
Collections.synchronized 래퍼 메서드가 반환하는 컬렉션들이 여기에 속한다.
◦
@ThreadSafe
•
스레드 안전하지 않음(not thread-safe)
◦
클래스의 인스턴스가 수정될 수 있고 내부 동기화가 되어있지 않아, 각각의 메서드 호출을 클라이언트에서 외부 동기화를 해주어야 하는 상태
◦
ArrayList, HashMap 같은 기본 컬렉션들이 여기에 속한다.
◦
@NotThreadSafe
•
스레드 적대적(thread-hostile)
◦
클래스의 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티 스레딩 환경에서 사용하기에는 스레드 안전이 보장되지 않는 상태
◦
정적 데이터를 아무 동기화 없이 수정하여 사용하는 경우에 해당하며, 일반적으로 이 수준의 스레드 안전 수준을 가지는 클래스는 Deprecated 된다.
스레드 안전 수준 문서화하기
•
조건부 스레드 안전한 클래스의 문서를 작성할 때는 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그 순서로 호출하려면 어떤 락을 얻어야 하는지 명시해야 한다.
Collections.synchronizedMap 문서 일부분
synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.
…
이대로 따르지 않으면 동작을 예측할 수 없다.
•
클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재하지만, 독특한 특성의 메서드라면 해당 메서드의 주석에 기재하자.
•
반환 타입만으로 명확히 알 수 없는 정적 팩터리라면, 반환하는 객체의 스래드 안전성을 반드시 문서화 해야한다.
공개 락과 비공개 락
•
클래스가 외부에서 사용할 수 있는 공개 락을 제공하면 클라이언트에서 메서드 호출을 원자적으로 수행할 수 있다.
•
하지만 이렇게 공개 락을 사용하면, 내부에서의 고성능 동시성 제어 유틸리티와는 동시에 사용하지 못하고 클라이언트가 공개된 락을 쥐고 놓지 않는 서비스 거부 공격(denial-of-service attack)을 받을 수 있다.
•
이런 서비스 거부 공격을 막기 위해서는 synchronized 메서드 대신 비공개 락 객체를 사용해야 한다.
private final Object lock = new Object();
public void foo() {
synchronized(lock) {
...
}
}
Java
복사
•
조건부 스레드 안전한 클래스에서는 특정 호출 순서에 필요한 락을 클라이언트에 공개해야하니, 이러한 비공개 락 객체는 무조건적 스레드 안전 클래스에서만 사용해야 한다.
•
이런 비공개 락으로 사용하면 해당 클래스를 상속할 때에도 이점이 있다. this를 통해 자신의 인스턴스를 락으로 사용한다면, 상속 받는 하위 클래스에서 동기화 동작을 아주 쉽게 방해하게 된다.
•
그러니 가급적 비공개 락을 사용하자.