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

스레드 스케줄러와 프로그램

• 스레드 스케줄러는 어떤 스레드를 얼마나 오래 실행할 지 정한다.

• 구체적인 스케줄링 정책은 운영체제마다 다르므로, 이 정책에 따라 성능이 변화하는 프로그램은 다른 플랫폼에 이식하기 어려워 좋은 프로그램이 아니다.

• 실행가능한 스레드의 평균 개수를 프로세서 수보다 지나치게 많지 않도록 해야 한다.

실행 가능한 스레드 개수 = (전체 스레드 개수) - (대기 중인 스레드 개수)

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

• 각 스레드가 유용한 작업을 완료한 후 다음 일거리가 생길 때까지 대기하도록 한다.

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

• ex) 실행자 프레임워크(ExecutorService)의 경우 스레드 풀 크기를 적절히 설정하고 작업은 짧게 유지하면 된다. 단, 너무 짧으면 작업을 분배하는 부담이 오히려 성능을 떨어트릴 수 있다.

바쁜 대기 상태

• 공유 객체의 상태가 바뀔 때까지 쉬지 않고 검사하는 상태

• 스레드 스케줄러의 변덕에 취약하고 프로세서에 큰 부담을 주어 다른 작업이 실행될 기회를 박탈한다.

• 스레드는 바쁜 대기 상태가 되면 성능과 이식성이 떨어질 수 있으므로 삼가야 한다.

• CountDownLatch의 await 메서드에서 무한반복문으로 상태를 검사하면, 해당 스레드는 쓸모없이 실행중인 상태가 된다.

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 시간을 얻어내는 것에 효과가 있을지 모르지만, 이식성 문제가 있다.

• JVM에 따라 성능이 달라질 수 있다. 처음에는 JVM의 성능을 높여줬지만 두 번째, 세 번째에서는 오히려 느려지게 할 수도 있다.

• 테스트할 수단이 없다.

• Thread.yield 대신 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치하도록 한다.

스레드 우선순위 조절 금지

• 스레드 우선순위는 자바에서 이식성이 가장 나쁜 특성에 속한다.

• 심각한 응답 불가 문제를 스레드 우선순위로 해결하려는 시도는 절대 합리적이지 않으며, 진짜 원인을 수정하기 전까지 같은 문제가 반복해서 생겨날 것이다.

• 프로그램을 고치는 용도로는 스레드 우선순위를 사용하지 말 것