: 여러 스레드가 동시에 접근할 때도 프로그램이 올바르게 동작하도록 보장하는 것을 의미
: 멀티 스레드 환경에서는 여러 스레드가 동시에 동일한 매서드를 호출하거나 동일한 데이터에 접근할 수 있기 때문에, 적절한 동기화 매커니즘 없이 공유자원에 접근하면 데이터 불일치, 레이스 컨디션, 데드락 등의 문제가 발생할 수 있음
public class Counter {
private int count = 0;
// 스레드 안전하지 않은 메서드
public void increment() {
count++;
}
public int getCount() {
return count;
}
}
동기화를 통해 스레드 안전하게 만들 수 있음
public class SynchronizedCounter {
private int count = 0;
// 동기화된 메서드
public synchronized void increment() {
count++;
}
public synchronized int getCount() {
return count;
}
}
synchronized?
synchronized 한정자는 Java에서 메서드나 블록에 대해 동기화를 적용하여 해당 코드가 동시에 하나의 스레드만 접근할 수 있도록 해줌.
특징
한 번에 하나의 스레드만 해당 메서드에 접근 가능
여러 스레드가 동시에 호출해도 동기화된 접근을 통해 데이터의 일관성을 유지 가능
🍑 본론
한 메서드를 여러 스레드가 동시에 호출할 때 그메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다.
API 문서에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다.
만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나, 지나치게 한 상태일 것이며 두가지 모두 심각한 오류로 이어질 수 있다.
API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 말을 들었을지 모르겠지만, 이 말은 몇가지 면에서 틀렸다.
자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다.
: 매서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다. 따라서 이것만으로는 그 메서드가 스레드 안전하다고 믿기 어렵다.
: synchronized 한정자는 메서드 구현의 세부 사항으로 간주 됨.
: API 문서는 클래스와 메서드의 공개 인터페이스를 설명하는 데 중점을 두기 때문에, synchronized 한정자는 인터페이스의 일부가 아닌 구현에 속한다고 볼 수 있다.
: API는 사용자가 클래스를 어떻게 사용할지 정의하는 것이며, 구현 세부사항은 클래스의 내부 작동 방식을 정의한다.
: synchronized 한정자는 메서드의 동작 방식을 결정하는 구현 세부사항으로, API 문서에서 반드시 포함될 필요는 없다.
synchronized 유무로 스레드 안전성을 알 수 있다는 주장은 '스레드 안전성은 모 아니면 도'라는 오해에 뿌리를 둔 것이다. 하지만 스레드 안전성에도 수준이 나뉜다.
: 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.
1. 불변(immutable)
: 불변 객체는 한 번 생성되면 상태가 변경되지 않는 객체.
: 따라서 여러 스레드가 동시에 접근하더라도 안전하다.
: 불변 객체는 외부 동기화가 필요 없음.
ex. String, Long, BigInteger
String str = "Hello, World!";
2. 무조건적 스레드 안전(unconditionally thread-safe)
: 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 동시에 사용해도 안전하다.
ex. AtomicLong, ConcurrentHashMap
AtomicLong atomicLong = new AtomicLong(0);
atomicLong.incrementAndGet(); // 여러 스레드에서 안전하게 호출 가능
3. 조건부 스레드 안전(conditionally thread-safe)
: 무조건적 스레드 안전과 같으나, 일부 메서드는 동시에 사용하려면 외부 동기화가 필요
: Collections.synchonized 래퍼 메서드가 반환한 컬렉션들이 여기 속한다.
: 리스트 자체는 스레드 안전하지만, 반복자는 외부 동기화가 필요하다.
: 따라서 이 컬렉션들이 반환하는 반복자는 외부에서 동기화해야 한다.
List<String> list = Collections.synchronizedList(new ArrayList<>());
synchronized (list) {
Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
}
4. 스레드 안전하지 않음(not thread-safe)
: 이 클래스의 인스턴스는 수정될 수 있다.
: 동시에 사용하려면 각각의 메서드 호출을 클라이언트가 선택한 외부 동기화 매커니즘으로 감싸야 한다.
ex. ArrayList, HashMap 같은 기본 컬렉션
List<String> list = new ArrayList<>();
synchronized (list) {
list.add("Hello");
}
5. 스레드 적대적(thread-hostile)
: 이 클래스는 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다.
: 이 수준의 클래스는 일반적으로 정적 데이터를 아무 동기화 없이 수정한다.
: 이런 클래스를 고의로 만드는 사람은 없겠지만, 동시성을 고려하지 않고 작성하다 보면 우연히 만들어질 수 있다.
: 스레드 적대적으로 밝혀진 클래스나 메서드는 일반적으로 문제를 고쳐 재배포하거나 사용 자제(decrecated) API로 지정한다.
: 아이템78의 generateSerialNumber 매서드에서 내부 동기화를 생략하면 스레드 적대적이게 된다.
public class ThreadHostile {
private static int counter = 0;
public void increment() {
counter++; // 동기화 없이 정적 변수 수정
}
}
이 분류는 스레드 안전성 애너테이션 (@Immutable,@ThreadSafe, @NotThreadSafe)과 대략 일치한다(스레드 적대적 제외).
앞 분류의 무조건적 스레드 안전과 조건부 스레드 안전은 모두 @ThreadSafe 애너테이션 밑에 속한다.
조건부 스레드 안전한 클래스는 주의해서 문서화해야 한다. 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그리고 그 순서로 호출하려면 어떤 락 혹은(드물게) 락들을 얻어야 하는지 알려줘야 한다.
일반적으로 인스턴스 자체를 락으로 얻지만 예외도 있다. 예를 들어 Collections.synchronizedMap의 API 문서에는 다음과 같이 써 있다.
// synchonizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라
Map<K,V> m = Collections.synchronizedMap(new HashMap<>());
Set<K> s = m.KeySet(); // 동기화 블록 밖에 있어도 된다.
....
synchronized(m){
for(K key : s)
key.f();
}
// 이대로 따르지 않으면 동작을 예측할 수 없다.
클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재하지만, 독특한 특성의 메서드라면 해당 메서드의 주석에 기재하도록 하자. 열거 타입은 굳이 불변이라고 쓰지 않아도 된다. 반환 타입으로만으로는 명확히 알 수 없는 정적 팩터리라면 자신이 반환하는 객체의 스레드 안전성을 반드시 문서화해야 한다. 앞서 Collections.synchronizedMap이 좋은 예다.
클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메서드 호출을 원자적으로 수행할 수 있다. 하지만 이 유연성에는 대가가 따른다. 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없게 되는 것이다. 그래서 ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 못한다. 또한, 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격을 수행할 수도 잇다.
서비스 거부 공격을 막으려면 비공개 락 객체를 사용해야 한다.
import java.util.concurrent.locks.ReentrantLock;
public class LockProvidingClass {
private final ReentrantLock lock = new ReentrantLock();
private int value;
public void increment() {
lock.lock();
try {
value++;
} finally {
lock.unlock();
}
}
public void decrement() {
lock.lock();
try {
value--;
} finally {
lock.unlock();
}
}
public int getValue() {
lock.lock();
try {
return value;
} finally {
lock.unlock();
}
}
// 클라이언트가 사용할 수 있는 락 제공
public ReentrantLock getLock() {
return lock;
}
}
LockProvidingClass는 getLock 메서드를 통해 ReentrantLock 객체를 외부에 제공.
클라이언트는 이 락을 사용하여 여러 메서드 호출을 원자적으로 수행할 수 있다.
import java.util.concurrent.locks.ReentrantLock;
public class PrivateLockClass {
private final ReentrantLock lock = new ReentrantLock();
private int value;
public void increment() {
lock.lock();
try {
value++;
} finally {
lock.unlock();
}
}
public void decrement() {
lock.lock();
try {
value--;
} finally {
lock.unlock();
}
}
public int getValue() {
lock.lock();
try {
return value;
} finally {
lock.unlock();
}
}
}
교재 비공개 락 예시
private final Object lock = new Object();
public void foo(){
synchronized(lock){
....
}
}
락을 외부에 노출하지 않고 내부에서만 사용하면 클라이언트가 락을 오래 소유할 수 없으며, 클래스 내부에서 동기화가 안전하게 이루어 진다.
비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다.
조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로, 이 관용구를 사용할 수 없다.
비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다. 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면, 하위 클래스는 아주 쉽게, 그리고 의도치 않게 기반 클래스의 동작을 방해할 수 있다. 같은 락을 다른 목적으로 사용하게 되어 하위 클래스와 기반 클래스는 '서로가 서로를 훼방놓는' 상태에 빠진다.
🍑 결론
모든 클래스가 자신의 스레드 안전성 정보를 명확히 문서화해야 한다.
정확한 언어로 명확히 설명하거나 스레드 안전성 애너테이션을 사용할 수 있다.
synchronized 한정자는 문서화와 관련이 없다.
조건부 스레드 안전 클래스는 메서드를 어떤 술서로 호출할 때 외부 동기화가 요구되고, 그때 어떤 락을 얻어야 하는지도 알려줘야 한다.
무조건적 스레드 안전 클래스를 작성할 때는 synchronized 메서드가 아닌 비공개 락 객체를 사용하자
이렇게 해야 클라이언트나 하위 클래스에서 동기화 매커니즘을 깨뜨리는 걸 예방할 수 있고, 필요하면 다음에 더 정교한 동시성을 제어 매커니즘으로 재구현할 여지가 생긴다.
Chapter : 11. 동시성
Item : 82. 스레드 안정성 수준을 문서화하라
Assignee : pyeong114
🍑 서론
스레드 안전성
: 여러 스레드가 동시에 접근할 때도 프로그램이 올바르게 동작하도록 보장하는 것을 의미 : 멀티 스레드 환경에서는 여러 스레드가 동시에 동일한 매서드를 호출하거나 동일한 데이터에 접근할 수 있기 때문에, 적절한 동기화 매커니즘 없이 공유자원에 접근하면 데이터 불일치, 레이스 컨디션, 데드락 등의 문제가 발생할 수 있음
동기화를 통해 스레드 안전하게 만들 수 있음
🍑 본론
한 메서드를 여러 스레드가 동시에 호출할 때 그메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다.
API 문서에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다.
만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나, 지나치게 한 상태일 것이며 두가지 모두 심각한 오류로 이어질 수 있다.
API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 말을 들었을지 모르겠지만, 이 말은 몇가지 면에서 틀렸다.
synchronized 유무로 스레드 안전성을 알 수 있다는 주장은 '스레드 안전성은 모 아니면 도'라는 오해에 뿌리를 둔 것이다. 하지만 스레드 안전성에도 수준이 나뉜다. : 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.
이 분류는 스레드 안전성 애너테이션 (
@Immutable
,@ThreadSafe
,@NotThreadSafe
)과 대략 일치한다(스레드 적대적 제외). 앞 분류의 무조건적 스레드 안전과 조건부 스레드 안전은 모두@ThreadSafe
애너테이션 밑에 속한다.조건부 스레드 안전한 클래스는 주의해서 문서화해야 한다. 어떤 순서로 호출할 때 외부 동기화가 필요한지, 그리고 그 순서로 호출하려면 어떤 락 혹은(드물게) 락들을 얻어야 하는지 알려줘야 한다.
일반적으로 인스턴스 자체를 락으로 얻지만 예외도 있다. 예를 들어 Collections.synchronizedMap의 API 문서에는 다음과 같이 써 있다.
클래스의 스레드 안전성은 보통 클래스의 문서화 주석에 기재하지만, 독특한 특성의 메서드라면 해당 메서드의 주석에 기재하도록 하자. 열거 타입은 굳이 불변이라고 쓰지 않아도 된다. 반환 타입으로만으로는 명확히 알 수 없는 정적 팩터리라면 자신이 반환하는 객체의 스레드 안전성을 반드시 문서화해야 한다. 앞서 Collections.synchronizedMap이 좋은 예다.
클래스가 외부에서 사용할 수 있는 락을 제공하면 클라이언트에서 일련의 메서드 호출을 원자적으로 수행할 수 있다. 하지만 이 유연성에는 대가가 따른다. 내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없게 되는 것이다. 그래서 ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 못한다. 또한, 클라이언트가 공개된 락을 오래 쥐고 놓지 않는 서비스 거부 공격을 수행할 수도 잇다.
서비스 거부 공격을 막으려면 비공개 락 객체를 사용해야 한다.
LockProvidingClass는 getLock 메서드를 통해 ReentrantLock 객체를 외부에 제공. 클라이언트는 이 락을 사용하여 여러 메서드 호출을 원자적으로 수행할 수 있다.
클라이언트가 락을 사용하는 경우
비공개 락 객체 사용
교재 비공개 락 예시
락을 외부에 노출하지 않고 내부에서만 사용하면 클라이언트가 락을 오래 소유할 수 없으며, 클래스 내부에서 동기화가 안전하게 이루어 진다.
비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다. 조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로, 이 관용구를 사용할 수 없다.
비공개 락 객체 관용구는 상속용으로 설계한 클래스에 특히 잘 맞는다. 상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면, 하위 클래스는 아주 쉽게, 그리고 의도치 않게 기반 클래스의 동작을 방해할 수 있다. 같은 락을 다른 목적으로 사용하게 되어 하위 클래스와 기반 클래스는 '서로가 서로를 훼방놓는' 상태에 빠진다.
🍑 결론
Referenced by
-