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

• 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할 지 정한다.
• 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다.
• 정책에 따라 성능이 달라지지 않게끔 잘 작성해야한다.

• 견고하고 빠릿하고 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다.
  • 요약 : 스레드 수 < 프로세서 수 유지

• 스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안된다.
• 실행자 프레임워크를 예로 들면 스레드 풀 크기를 적절히 설정하고 작업은 짧게 유지하면 된다.
• 단 너무 짧으면 작업을 분배하는 부담이 오히려 성능을 떨어트릴수도 있다.

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

//끔찍한 CountDownLatch 구현 - 바쁜 대기 버전

public class SlowCountDownLatch {
    private int count;

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

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

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

• 특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌아가는 프로그램을 보더라도 Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자

정리

• 프로그램의 핵심 동작을 스레드 스케줄러에 기대지 말자
• 견고성과 이식성을 모두 해치는 경우다.
• 같은 이유로 Thread.yield와 스레드 우선순위에 의존해서도 안된다.