티스토리 뷰
반응형
스레드 안전성
- 한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하는 지는 해당 클래스와 사용자와의 중요한 계약이다.
- 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않음 그래서 그것만으로 스레드 안전하다고는 할 수 없음
- 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야함
- 스레드 안전성이 높은 순
- 불변(immutable) : 이 클래스의 인스턴스는 마치 상수같아서 외부 동기화도 필요 없음. ex) String, Long, BigInteger [아이템 7]
- 무조건적 스레드 안전 : 이 클래스의 인스턴스는 수정될 수 있으나 내부에서 잘 동기화하여 외부 동기화 없이 동시에 사용해도 안전하다. ex) AtomicLong, ConcurrentHashMap
- 조건부 스레드 안전 : 무조건적 스레드 안전과 같으나 일부 메서드는 동시 사용을 위해 외부 동기화가 필요. ex) Collections.synchronized 래퍼 메서드가 반환한 컬렉션들
- 스레드 안전하지 않음 : 이 클래스의 인스턴스는 수정될 수 있음, 동시 사용 위해 각각의 메서드 호출을 외부 동기화로 감싸야함. ex) ArrayList, HashMap 같은 기본 컬렉션
- 스레드 적대적 : 모든 메서드 호출을 외부 동기화로 감싸도 멀티스레드 환경에서 안전하지 않음, 이 수준의 클래스는 보통 정적 데이터를 아무 동기화 없이 수정함, 재배포되거나 deprecated API로 지정한다.
스레드 안전성 애너테이션
- @Immutable
- @ThreadSafe : 무조건적 스레드 안전, 조건부 스레드 안전
- @NotThreadSafe
스레드 안전성 수준 문서화
- 조건부 스레드 안전한 클래스는 어떤 순서로 호출할 때 외부 동기화가 필요한 지, 그 순서로 호출하려면 어떤 락 / 락들을 얻어야 하는 지 주의해서 문서화
- 클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재, 독특한 메서드라면 해당 메서드의 주석에 기재
- 반환 타입만으로 알 수 없는 정적 팩터리라면 반환하는 객체의 스레드 안전성을 반드시 문서화
// Collections.synchronizedMap API 예시
synchornizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.
Map<K, V> m = Collections.synchronizedMap(new HashMap<>());
Set<K> s = m.keySet(); // 동기화 불록 밖에 있어도 된다.
synchronized(m) { // s가 아닌 m을 사용해 동기화 해야한다!
for (K key : s)
key.f();
}
공개 락 vs 비공개 락
- 클래스가 외부에서 사용할 수 있는는 락을 제공하면 일련의 메서드 호출을 원자적으로 수행 가능
- ConcurrentHashMap 같은 동시성 컬렉션과 함께 사용 못함
- 클라이언트가 공개된 락을 오래쥐고 안놓는 서비스 거부 공격 위험
- 이를 막기 위해서는 synchornized 메서드(공개 락) 대신 비공개 락 객체 사용해야함 → 비공개 락 객체는 외부에서 볼 수 없어서 동기화에 관여할 수 없다. (캡슐화)
- 비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용 가능
- 비공개 락 객체 관용구는 상속용 클래스에 더 잘맞는다. 상속용 클래스에서 자신의 인스턴스를 락으로 사용하면 하위 클래스는 아주 쉽게 의도치 않게 기반 클래스의 동작을 방해할 수 있다.
//비공개 락 객체 관용구 - 서비스 거부 공격을 막아준다.
private final Object lock = new Object(); //락 필드는 항상 final로 선언하라.
public void foo() {
synchronized(lock) {
...
}
}
결론
- 모든 클래스가 자신의 스레드 안전성을 문서화해야함
- synchronized 한정자는 문서화와 관련이 없음
- 조건부 스레드 안전 클래스는 어떤 순서로 메서드를 호출할 때 외부 동기화가 필요하고 어떤 락을 얻어야하는 지 문서화해야함
- 무조건적 스레드 안전 클래스는 synchronized 메서드가 아닌 비공개 락 객체를 사용하자. → 클라이언트나 하위 클래스에서 동기화 메커니즘 깨는 것을 예방할 수 있음
반응형
'Java > Effective Java' 카테고리의 다른 글
[Effective Java] 84.프로그램의 동작을 스레드 스케줄러에 기대지말라 (0) | 2022.05.08 |
---|---|
[Effective Java] 83.지연 초기화는 신중히 사용하라 (0) | 2022.05.08 |
[Effective Java] 81.wait와 notify보다는 동시성 유틸리티를 사용하라 (0) | 2022.04.19 |
[Effective Java] 80.스레드보다는 실행자, 태스크, 스트림을 애용하라 (0) | 2022.04.19 |
[Effective Java] 79.과도한 동기화는 피하라 (0) | 2022.04.19 |
댓글