Item 82 & 83 & 84 스레드 안전성 문서화 / 지연 초기화 / 스레드 스케쥴러

[ChaCha3088]

section: 11장 동시성

• Item 82 스레드 안전성 수준을 문서화하라
• Item 83 지연 초기화는 신중히 사용하라
• Item 84 프로그램의 동작을 스레드 스케쥴러에 기대지 말라

---

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

💡 한 메서드를 여러 스레드가 동시에 호출할 때, 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다.

API 문서에서 아무런 언급도 없으면, 그 클래스 사용자는 나름의 가정을 해야만 한다. 만약 그 가정이 틀리면, 클라이언트 프로그램은 동기화를 충분히 하지 못하거나(아이템 78) 지나치게 한(아이템 79) 상태일 것이며, 두 경우 모두 심각한 오류로 이어질 수 있다.

API 문서에 synchronized 한정자가 보이는 메서드

이 메서드는 스레드 안전하다는 이야기를 들었을지 모르겠다.
하지만 이 말은 몇 가지 면에서 틀렸다.
Java Doc이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자를 선언할지는 구현 이슈일 뿐, API에 속하지 않는다.
따라서 이것만으로는 그 메서드가 스레드 안전하다고 믿기 어렵다.

클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.

더구나 synchronized 유무로 스레드 안전성을 알 수 있다는 주장은 “스레드 안전성은 모 아니면 도”라는 오해에 뿌리를 둔 것이다.
하지만 스레드 안전성에도 수준이 나뉜다.

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

스레드 안전성

다음 목록은 스레드 안전성이 높은 순으로 나열한 것이다.

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

스레드 안전성 어노테이션

이 분류는 [자바 병렬 프로그래밍]의 부록 A에 나오는 스레드 안전성 어노테이션(@Immutable, @ThreadSafe, @NotThreadSafe)과 대략 일치한다.
앞 분류의 무조건적 스레드 안전과 조건부 스레드 안전은 모두 @ThreadSafe 어노테이션 밑에 속한다.

문서화 할 때 주의

어떤 순서로 호출할 때 외부 동기화가 필요한지, 그리고 그 순서로 호출하려면 어떤 락 혹은 락들을 얻어야 하는지 알려줘야 한다.
일반적으로 인스턴스 자체를 락으로 얻지만 예외도 있다.
예를 들어 Collections.synchronizedMap의 API 문서에는 다음과 같이 써 있다.

// synchronizedMap이 반환한 맵의 컬렉션 뷰를 순회하려면 반드시 그 맵을 락으로 사용해 수동으로 동기화하라.

Map<K, V> m = Collections.synchronizedMap(new HashMap<>());
Set<K> s = m.keySet(); // 동기화 블록 밖에 있어도 된다.
...
synchronized(m) { // s가 아닌 m을 사용해 동기화해야 한다!
	for (K key : s) {
		key.f();
	}
}

// 이대로 따르지 않으면 동작을 예측할 수 없다.

주석의 위치

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

클래스가 외부에서 사용할 수 있는 락을 제공하면

클라이언트에서 일련의 메서드 호출을 원자적으로 수행할 수 있다.
하지만 이 유연성에는 대가가 따른다.
내부에서 처리하는 고성능 동시성 제어 메커니즘과 혼용할 수 없게되는 것이다.
그래서 ConcurrentHashMap 같은 동시성 컬렉션과는 함께 사용하지 못한다. 또한, 클라이언트가 공개된 락을 오래 쥐고 놓치 않는 서비스 거부 공격(Denial of Service Attack)을 수행할 수도 있다.

비공개 락 객체 관용구

서비스 거부 공격을 막으려면 synchronized 메서드(이 역시 공개된 락이나 마찬가지다) 대신 비공개 락 객체를 사용해야 한다.

// 비공개 락 객체 관용구 - 서비스 거부 공격을 막아준다.
private final Object lock = new Object();

public void foo() {
	synchronized(lock) {
		...
	}
}

// lock 필드를 final로 선언하면 우연히라도 락 객체가 교체되는 일을 예방해준다.
// 락이 교체되면 끔찍한 결과로 이어진다. (아이템 78)
// 아이템 17의 조언을 따라 다시 한번 락 필드의 변경 가능성을 최소화한 것이다.
// 이 예처럼 **락 필드는 항상 final로 선언하라.**

비공개 락 객체는 클래스 바깥에서는 볼수 없으니, 클라이언트가 그 객체의 동기화에 관여할 수 없다.
사실 아이템 15의 조언을 따라 락 객체를 동기화 대상 객체 안으로 캡슐화한 것이다.

💡 비공개 락 객체 관용구는 무조건적 스레드 안전 클래스에서만 사용할 수 있다.

조건부 스레드 안전 클래스에서는 특정 호출 순서에 필요한 락이 무엇인지를 클라이언트에게 알려줘야 하므로, 이 관용구를 사용할 수 없다.

적용

💡 비공개 락 객체 관용구는 상속용으로 설계한 클래스(아이템 19)에 특히 잘 맞는다.

상속용 클래스에서 자신의 인스턴스를 락으로 사용한다면, 하위 클래스는 아주 쉽게, 그리고 의도치 않게 기반 클래스의 동작을 방해할 수 있다.
같은 락을 다른 목적으로 사용하게 되어, 하위 클래스와 기반 클래스는 “서로가 서로를 훼방놓는” 상태에 빠진다.
단지 가능성에 그치지 않고, 실제로 Thread 클래스에서 나타나곤 하는 문제다.

정리

1. 모든 클래스가 자신의 스레드 안전성 정보를 명확히 문서화해야 한다.
   1. 정확한 언어로 명확히 설명하거나 스레드 안전성 어노테이션 사용
2. synchronized 한정자는 문서화와 관련이 없다.
3. 조건부 스레드 안전 클래스는 메서드를 어떤 순서로 호출할 때 외부 동기화가 요구되고, 그 때 어떤 락을 얻어야 하는지도 알려줘야 한다.
4. 무조건적 스레드 안전 클래스를 작성할 때는 synchronized 메서드가 아닌 비공개 락 객체를 사용하자.

83. 지연 초기화는 신중히 사용하라

💡 지연 초기화(Lazy Initialization)는 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법이다.

그래서 값이 전혀 쓰이지 않으면 초기화도 결코 일어나지 않는다.

적용 위치

이 기법은 정적 필드와 인스턴스 필드 모두에 사용할 수 있다.

효과

지연 초기화는 주로 최적화 용도로 쓰이지만, 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다.

최선의 조언

💡 “필요할 때까지는 하지 말라” (아이템 67)

지연 초기화는 양날의 검이다.
클래스 혹은 인스턴스 생성 시의 초기화 비용은 줄지만, 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다.
지연 초기화하려는 필드들 중 결국

• 초기화가 이뤄지는 비율에 따라
• 실제 초기화에 드는 비용에 따라
• 초기화된 각 필드를 얼마나 빈번히 호출하느냐에 따라
  지연 초기화가 실제로는 성능을 느려지게 할 수 도 있다.

필요할 때

해당 클래스의 인스턴스 중 그 필드를 사용하는 인스턴스의 비율이 낮은 반면, 그 필드를 초기화하는 비용이 크다면 지연 초기화가 제 역할을 해줄 것이다.
하지만 안타깝게도 정말 그런지를 알 수 있는 유일한 방법은 지연 초기화 적용 전후의 성능을 측정해보는 것이다.

멀티스레드 환경에서는

지연 초기화를 하기가 까다롭다.

💡 지연 초기화하는 필드를 둘 이상의 스레드가 공유한다면, 어떤 형태로든 반드시 동기화해야 한다.

그렇지 않으면 심각한 버그로 이어질 것이다. (아이템 78)

대부분의 상황에서

일반적인 초기화가 지연 초기화보다 낫다.

초기화 방법

다음은 인스턴스 필드를 선언할 때 수행하는 일반적인 초기화의 모습이다.
final 한정자를 사용했음에 주목하자. (아이템 17)

// 인스턴스 필드를 초기화하는 일반적인 방법
private final FieldType field = computeFieldValue();

지연 초기화가 초기화 순환성(Initialization Circularity)를 깨뜨릴 것 같으면, synchronized를 단 접근자를 사용하자.

// 인스턴스 필드의 지연 초기화 - synchronized 접근자 방식
private FieldType field;

private synchronized FieldType getField() {
	if (field == null) {
		field = computeFieldValue();
	
	return field;
}

이상의 두 관용구는 정적 필드에도 똑같이 적용된다.
물론 필드와 접근자 메서드 선언에 static 한정자를 추가해야 한다.

지연 초기화 홀더 클래스 관용구

성능 때문에 정적 필드를 지연 초기화해야 한다면, 지연 초기화 홀더 클래스(Lazy Initialization Holder Class) 관용구를 사용하자.
클래스는 클래스가 처음 쓰일 때 비로소 초기화된다는 특성을 이용한 관용구다. [JLS, 12.4.1]

// 정적 필드용 지연 초기화 홀더 클래스 관용구
private static class FieldHolder {
	static final FieldType field = computeFieldValue();
}

private static FieldType getField() {
	return FieldHolder.field;
}

getField가 처음 호출되는 순간 FieldHolder.field가 처음 읽히면서, FieldHolder 클래스 초기화를 촉발한다.
이 관용구의 멋진 점은 getField 메서드가 필드에 접근하면서 동기화를 전혀 하지 않으니, 성능이 느려질 거리가 전혀 없다는 것이다.
일반적인 VM은 오직 클래스를 초기화할 때만 필드 접근을 동기화할 것이다.
클래스 초기화가 끝난 후에는 VM이 동기화 코드를 제거하여, 그 다음부터는 아무런 검사나 동기화 없이 필드에 접근하게 된다.

이중 검사(Double-Check) 관용구

성능 때문에 인스턴스 필드를 지연 초기화해야 한다면 이중 검사(Double-Check) 관용구를 사용하라.
이 관용구는 초기화된 필드에 접근할 때의 동기화 비용을 없애준다. (아이템 79)
이름에서 알 수 있듯, 필드의 값을 두번 검사하는 방식으로, 한번은 동기화 없이 검사하고, 필드가 아직 초기화되지 않았다면 두번째는 동기화하여 검사한다.
두번째 검사에서도 필드가 초기화되지 않았을 때만 필드를 초기화한다.
필드가 초기화된 후로는 동기화하지 않으므로, 해당 필드는 반드시 volatile 로 선언해야 한다. (아이템 78)

// 인스턴스 필드 지연 초기화용 이중 검사 관용구
private volatile FieldType field;

private FieldType getField() {
	FieldType result = field;
	
	if (result != null) { // 첫번째 검사(락 사용 X)
		return result;
	}

	synchronized(this) {
		if (field == null) { // 두번째 검사(락 사용)
			field = computeFieldValue();
		}
	
		return field;
	}
}

코드가 다소 난해할 것이다.
특히 result라는 지역 변수가 필요한 이유는 뭘까?
이 변수는 필드가 이미 초기화된 상황(일번적인 상황)에서는 그 필드를 딱 한번만 읽도록 보장하는 역할을 한다.
반드시 필요하지는 않지만, 성능을 높여주고, 저수준 동시성 프로그래밍에 표준적으로 적용되는 더 우아한 방법이다.
이중 검사를 정적 필드에도 적용할 수 있지만, 굳이 그럴 이유는 없다.
이보다는 지연 초기화 홀더 클래스 방식이 더 낫다.

변종

이중 검사에는 언급해둘만한 변종이 두가지 있다.

단일 검사(Single-Check)

이따금 반복해서 초기화해도 상관없는 인스턴스 필드를 지연 초기화해야 할 때가 있는데, 이런 경우라면 이중 검사에서 두번째 검사를 생략할 수 있다.
이 변종의 이름은 자연히 단일 검사(Single-Check) 관용구가 된다.
필드는 여전히 volatile로 선언했음을 확인하자.

// 단일 검사 관용구 - 초기화가 중복해서 일어날 수 있다!
private volatile FieldType field;

private FieldType getField() {
	FieldType result = field;

	if (result == null) {
		field = result = computeFieldValue();
	
	return result;
}

이번 아이템에서 이야기한 모든 초기화 기법은 기본 타입 필드와 객체 참조 필드 모두에 적용할 수 있다.
이중 검사와 단일 검사 관용구를 수치 기본 타입 필드에 적용한다면, 필드의 값을 null 대신 0과 비교하면 된다.

짜릿한 단일 검사(Racy Single-Check)

모든 스레드가 필드의 값을 다신 계산해도 상관 없고 필드의 타입이 long과 double을 제외한 다른 기본 타입이라면, 단일 검사의 필드 선언에서 volatile 한정자를 없애도 된다.
이 관용구는 어떤 환경에서는 필드 접근 속도를 높여주지만, 초기화가 스레드당 최대 한번 더 이뤄질 수 있다.
아주 이례적인 기법으로, 보통은 거의 쓰지 않는다.

정리

1. 대부분의 필드는 지연시키지 말고 곧바로 초기화해야 한다.
2. 성능 때문에 / 위험한 초기화 순환을 막기 위해 꼭 써야한다면 올바른 지연 초기화 기법을 사용하자.
3. 인스턴스 필드에는 이중 검사 관용구를, 정적 필드에는 지연 초기화 홀더 클래스 관용구를 사용하자.
4. 반복해 초기화해도 괜찮은 인스턴스 필드에는 단일 검사 관용구도 고려 대상이다.

84. 프로그램의 동작을 스레드 스케쥴러에 기대지 말라

여러 스레드가 실행 중이면 운영체제의 스레드 스케쥴러가 어떤 스레드를 얼마나 오래 실행할지 정한다. 정상적인 운영체제라면 이 작업을 공정하게 수행하지만, 구체적인 스케쥴링 정책은 운영체제마다 다를 수 있다. 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지돼서는 안된다.

💡 정확성이나 성능이 스레드 스케쥴러에 따라 달라지는 프로그램이라면, 다른 플랫폼에 이식하기 어렵다.

가장 좋은 방법

견고하고 빠릿하고 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 그래야 스레드 스케쥴러가 고민할 거리가 줄어든다.
실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자. 이런 프로그램이라면 스레드 스케쥴링 정책이 아주 상이한 시스템에서도 동작이 크게 달라지지 않는다.
여기서 실행 가능한 스레드의 수와 전체 스레드 수는 구분해야 한다. 전체 스레드 수는 훨씬 많을 수 있고, 대기중인 스레드는 실행 가능하지 않다.

실행 가능한 스레드 수를 적게 유지하는 주요 기법

각 스레드가 무언가 유용한 작업을 완료한 후에는 다음 일거리가 생길 때까지 대기하도록 하는 것이다.
스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안된다.
실행자 프레임워크(아이템 80)를 예로 들면, 스레드 풀 크기를 적절히 설정하고[Goetz06, 8.2] 작업은 짧게 유지하면 된다. 단, 너무 짧으면 작업을 분배하는 부담이 오히려 성능을 떨어뜨릴 수도 있다.

스레드는 절대 바쁜 대기(Busy Waiting) 상태가 되면 안된다.

공유 객체의 상태가 바뀔 때까지 쉬지 않고 검사해서는 안된다는 뜻이다.
바쁜 대기는 스레드 스케쥴러의 변덕에 취약할 뿐 아니라, 프로세서에 큰 부담을 주어 다른 유용한 작업이 실행될 기회를 박탈한다.

// 끔찍한 CountDownLatch 구현 - 바쁜 대기 버전!
public class SlowCountDownLatch {
	private int count;

	public SlowCountDownLatch(int count) {
		if (count < 0) {
			throw new IllegalArgumentException(count + " < 0");
		
		this.count = count;
	}

	public void await() {
		while (true) {
			synchronized(this) {
				if (count == 0) {
					return;
				}
			}
		}
	}

	public synchronized void countDown() {
		if (count != 0) {
			count--;
		}
	}
}

이런 코드는 Java의 CountDownLatch와 비교해보니 약 10배가 느렸다.
하나 이상의 스레드가 필요도 없이 실행 가능한 상태인 시스템은 흔하게 볼 수 있다. 이런 시스템은 성능과 이식성이 떨어질 수 있다.

Thread.yield

특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌아가는 프로그램을 보더라도, Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자.
증상이 어느 정도는 호전될 수도 있지만, 이식성은 그렇지 않을 것이다.
처음 JVM에서는 성능을 높여준 yield가 두번째 JVM에서는 아무 효과가 없고, 세번째에서는 오히려 느려지게 할 수도 있다.
Thread.yield는 테스트할 수단도 없다.
차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치해주자.

스레드 우선순위 조절?

이런 상황에서 스레드 우선순위를 조절하는 방법도 있지만, 역시 비슷한 위험이 따른다.
스레드 우선순위는 Java에서 이식성이 가장 나쁜 특성에 속한다.
스레드 몇 개의 우선순위를 조율해서 애플리케이션의 반응 속도를 높이는 것도 일견 타당할 수 있으나, 정말 그래야할 상황은 드물고, 이식성이 떨어진다.
심각한 응답 불가 문제를 스레드 우선순위로 해결하려는 시도는 절대 합리적이지 않다.
진짜 원인을 찾아 수정하기 전까지 같은 문제가 반복해서 터져 나올 것이다.

정리

1. 프로그램의 동작을 스레드 스케쥴러에 기대지 말자.
   1. 견고성과 이식성을 모두 해친다.
2. 같은 이유로, Thread.yield와 스레드 우선순위에 의존해서도 안된다.
   1. 이 기능들은 스레드 스케쥴러에 지공하는 힌트일 뿐이다.
3. 스레드 우선순위는 이미 잘 동작하는 프로그램의 서비스 품질을 높이기 위해 드물게 쓰일 수는 있지만, 간신히 동작하는 프로그램을 “고치는 용도”로 사용해서는 절대 안된다.

---

reference