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

1. Thread Scheduler

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

이 스레드 스케줄링 정책은 OS다를 수 있기 때문에, 프로그램은 이 정책에 좌지우지 되어서는 안된다.

현재 프로그램을 XX스케줄링에 맞춰 작성해서, macOS의 스케줄링은 XX 우선이므로 macOS 상에서 프로그램이 정상적으로 동작한다.. 이런식의 프로그램 정책이 말이 안된다는 소리이다.

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

 

2. 이식성 좋은 프로그램을 작성하는 방법

핵심 : 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것

전체 스레드수 = 대기중인 스레드수(실행 가능하지 않은 스레드 수) + 실행중인 스레드 수

 

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

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

각 스레드가 무언가 유용한 작업을 완료한 후에는 다음 일거리가 생길 때까지 대기하도록 하는 것
ex) 스레드 풀 크기를 적절히 설정하고, 작업은 짧게 유지한다. (작업 분배가 성능을 떨어뜨릴 수도 있음)

스레드는 절대 바쁜 대기(busy waiting) 상태가 되면 안된다.
=> 공유 객체의 상태가 바뀔때까지 쉬지 않고 검사해서는 안된다.

public class SlowCountDownLatch { // 바쁜 대기 버전 CountDownLatch 구현
  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--;
  }
}

하나의 스레드가 필요도 없이 실행가능한 상태인 시스템은 성능과 이식성이 떨어질 수 있다.

 

3. 이식성이 나쁜 코드

Thread.yield

• Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자
• Thread.yield는 테스트할 수단도 없다.

특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌아가는 프로그램을 고친답시고 사용해도, JVM 버전 혹은, JVM 종류에 따라서 성능이 달라지는 것은 올바르지 않다.

차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치하자.

 

Thread Priority

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

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