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

이식성을 높이는 방법

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

(1) 실행 가능한 스레드의 평균적인 수를 프로세스 수보다 지나치게 많아지지 않도록 하라.

• 그래야 스케줄러가 고민할 거리가 줄어든다.
• 실행 준비가 된 스레드들은맡은 작업을 완료할 때까지 계속 실행되도록 만들어라.

• 전체 스레드 수는 훨씬 많을 수 있고, 대기 중인 스레드는 실행 가능하지 않다.

  실행 가능한 스레드 수를 구분하라는 의미

(2) 각 스레드가 어떤 유용한 작업을 완료한 후에 다음 일거리가 생길 때까지 대기하도록 만들어라.

• 실행 가능한 스레드 수를 적게 유지하는 주요 기법
• 스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다.
• 실행자 프레임워크의 경우, 스레드 풀 크기를 적절히 설정하고 작업을 짧게 유지하면 된다.
  • 단, 너무 짧으면 작업을 분배하는 부담이 오히려 성능을 저하시킬 수 있다.

피해야 할 상황 🙅‍♀️

(1) 스레드는 절대 바쁜 대기(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--;
    }
}

• 바쁜 대기는 스레드 스케줄러의 변덕에 취약하고, 프로세서에 큰 부담을 주어 다른 유용한 작업이 실행될 기회를 박탈한다.
• 하나 이상의 스레드가 필요도 없이 실행 가능한 상태인 시스템은 성능, 이식성이 떨어질 수 있다.

(2) Thread.yield에 의존해선 안된다.

• Thread.yield란?
  • JVM의 스레드 스케줄러에 현재 스레드의 우선 순위를 낮춰도 된다는 힌트를 보내는 메서드
• 명령이 아니라 ‘힌트’이기 때문에, 무조건 반영된다는 보장이 없다.
• 예측이 불가능하므로 프로그램의 안전성과 일관성을 해칠 수 있다.
  • 이식성이 떨어지고, 테스트할 수단도 없다.
• 차라리 애플리케이션 구조를 개선하여 동시에 실행 가능한 스레드 수가 적어지도록 조치하자.

(3) 스레드 우선 순위에 의존해서도 안된다.

• 스레드 우선 순위는 자바에서 이식성이 가장 나쁜 특성에 속한다.
• 심각한 응답 불가 문제를 스레드 우선 순위로 해결하려는 시도는 절대 합리적이지 않다.
  • 진짜 원인을 찾아 수정하자.

💡 핵심 정리

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