[EffectiveJava] item84 - 프로그램의 동작을 스레드 스케줄러에 기대지 말라

여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다.

정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다.

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

이식성 좋은 프로그램 작성법

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

이런 프로그램이라면 스레드 스케줄링 정책이 아주 상이한 시스템에서도 동작이 크게 달라지지 않는다.

스레드 수를 적게 유지하는 기법

실행 가능한 스레드 수를 적게 유지하는 주요 기법은 각 스레드가 무언가 유용한 작업을 완료한 후에 다음 일거리가 생길 때까지 대기하도록 하는것이다.

스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다.

스레드의 주의할 점

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

이런 시스템은 성능과 이식성이 떨어질 수 있다.

Thread.yield을 지양하자

특정 스레드가 다른 스레드에 비해 CPU 시간을 충분히 얻지 못한다 해도 Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자.

처음 JVM에서는 성능을 높여준 yield가 두번째 JVm에서는 아무런 효과가 없고, 세 번째에서는 오히려 느려지게 할 수 있다.

Thread.yield는 테스트할 수단도 없다. 차라리 애플리케이션의 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치하자.

스레드 우선순위 조절의 위험

스레드 우선순위를 조절하는 방법도 있지만, 역시 비슷한 위험이 따른다. 스레드 우선순위는 자바에서 이식성이 가장 나쁜 특성에 속한다.

스레드 몇 개의 우선순위를 조율해서 애플리케이션의 반응 속도를 높이는 것은 일견 타당할 수 있으나, 정말 그래야할 상황은 드물고, 이식성이 떨어진다.

또한 심각한 응답 불가 문제를 우선순위로 해결하려는 시도는 절대 합리적이지 않다. 근본 원인을 해결하기 전에는 같은 문제가 반복해서 터져나올 것이다