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

[windowforsun]

스레드 스케줄러

• 실행 중인 스레드는 운영체제의 스레드 스케줄러 에 의해 관리된다.
• 스레드 스케줄러 정책은 운영체제마다 다를 수 있다.
• 위 2가지로 인해 스레드 스케줄러 에 의존하게 되면 환경 따라 프로그램이 영향을 받을 수 있다.
• 스레드 스케줄러 에 따라 정확도, 성능이 달라지는 프로그램은 플랫폼 이식성이 떨어진다.

이식성이 좋은 프로그램

• 실행 가능한 스레드의 평균적인 수를 프로세서 수 보다 지나치게 많게 해서는 안된다.
  • 지나치게 많다면 프로그램이 스레드 스케줄러 에 크게 의존하게 된다.
• 실행 준비가 된 스레드는 작업 완료까지 계속 수행 되도록 구현해야 한다.
  • 완료까지 계속 수행된다면 스레드 스케줄러 영향을 덜 받아 플랫폼 이식성이 높다.

실행 가능한 스레드의 평균 수 줄이기

• 스레드는 당장 처리할 작없이 없다면 실행해서는 안된다.
• 스레드는 현재 작업을 완료하면 그 다음 작업까지 대기하도록 해야 한다.
• 실행자 프레임워크(#80 ) 를 예로 스레드 풀 크기는 적절한 크기로 설정하고, 작업은 짧게 유지한다.
  • 단, 너무 짧은 작업은 빈번한 분배과정으로 오히려 성능 저하가 발생할 수 있다.

바쁜 대기(BUSY WAITING)를 피하기

• 공유 객체의 상태검사와 같은 작업은 피해야 한다.
• 이러한 스레드의 바쁜 대기 상태는 프로세서에 큰 부담을 주어 유용한 작업 할당 기회가 줄어 든다.

public class SlowCountDownLatch {
    private int count;

    public SlowCountDownLatch(int count) {
        this.count = count;
    }

    // 프로세서에 큰 부담을 주는 상태 검사
    public void await() {
        while(true) {
            synchronized (this) {
                if(this.count == 0) {
                    return;
                }
            }
        }
    }

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

• java.util.concurrent.CountDownLatch 보다 10배 정도 느리다.
• 하나 이상의 스레드가 불필요하게 실행 가능한 상태 를 갖는건 성능과 플랫폼 이식성이 떨어진다.

Thread.yield 사용하지 않기

• [Thread.yield](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Thread.html#yield()) : 호출한 스레드는 실행 대기 상태로 돌아가고, 동일하거나 높은 우선순위 다른 스레드가 실행 기회를 갖도록 양보
• JVM 마다(플랫폼 마다) 명확한 동작을 증명 할 수 없다. (이식성이 나쁘다.)
• 테스트 방안도 없다.
• 이러한 스레드 우선순위를 강제로 조절하는 것은 이식성이 나쁜 가장 좋은 예이다.
• 정말로 필요한 상황이 있을 순 있지만, 굉장히 드믈고 모든 플랫폼에서 성능 향상을 보장 할 수 없다.
• 성능 저하의 진짜 원인을 찾는 것이 가장 좋은 해결 방안이다.