[아이템 84] 프로그램의 동작을 스레드 스케줄러에 기대지 말라

[sso9594]

📌 [아이템 84] 프로그램의 동작을 스레드 스케줄러에 기대지 말라

✨ 핵심 내용

잘 작성된 프로그램은 스케줄러에 영향을 받지 않는다.

스케줄링 정책은 운영체제마다 다르다.

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

좋은 프로그램 만들기

• 실행 가능한 스레드의 평균 수를 프로세서 수보다 지나치게 많아지지 않도록 조절
  • 이래야 스케줄러의 연산이 적어짐
• 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행
  • 이런 프로그램이면 스케줄링 정책이 이상해도 동작이 크게 달라지지 않음
  • 전체 스레드와 실행 가능한 스레드를 잘 구분할 것

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

스레드가 작업을 완료한 후 다음 일거리까지 대기하게 만들기

• 스레드는 당장 처리해야할 작업이 없다면 실행돼서는 안됨
• 스레드 풀 크기를 적절히 설정하고 작업을 짧게 유지 → 너무 짧으면 오버헤드가 커짐

스레드는 절대 busy waiting 상태가 되어서는 안됨

• 동유 객체의 상태가 바뀔 때 까지 쉬지 않고 검사해서는 안됨
• 스케줄러에도 취약하고 프로세서에도 부담

public class SlowCountDownLatch {
	private int count;

	// 생성자: 카운트가 0보다 작으면 예외
	public SlowCountDownLatch(int count) {
		if (count < 0)
			throw new IllegalArgumentException(count + " < 0");
		this.count = count;
	}

	// 대기: count가 0이 될 때까지 계속 대기
	public void await() {
		while (true) {
			synchronized(this) {
				if (count == 0)
					return;
			}
		}
	}

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

• Thread.yield() 사용은 피하라

  • Thread.yield() : 현재 실행 중인 스레드가 CPU를 잠깐 양보

  → 일부 JVM에선 효과 있지만, 다른 JVM에선 무의미하거나 오히려 느려질 수 있음

  → 테스트 불가능 + 이식성 최악

• 스레드 우선순위 조절도 비추천

  → 플랫폼마다 동작 방식이 달라 예측 불가능하고 이식성 없음

  → 일시적 효과는 있어 보여도 진짜 원인 해결이 아님

• 권장 대안

  → 스레드 수 줄이기 등 애플리케이션 구조를 바꾸는 것이 근본적인 해결책

💡 새롭게 알게 된 점

• 학습하면서 이전과 다르게 이해한 점이나 새롭게 알게 된 개념을 공유해주세요.

📚 정리

• 핵심 내용을 정리해주세요.
• 해당 개념을 실제 프로젝트에서 어떻게 활용할 수 있을지 아이디어를 공유해주시면 더 좋아요!

---

📢 댓글로 각자의 학습 내용을 공유해주세요!