[이펙티브 자바] Item 84 프로그램의 동작을 스레드 스케줄러에 기대지 말라.

핵심 정리

프로그램의 동작을 스레드 스케줄러에 기대지 말자. 견고성과 이식성을 모두 해치는 행위다. 같은 이유로, Thread.yield와 스레드 우선순위에 의존해서도 안 된다. 이 기능들은 스레드 스케줄러에 제공하는 힌트일 뿐이다. 스레드 우선순위는 이미 잘 동작하는 프로그램의 서비스 품질을 높이기 위해 드물게 쓰일 수는 있지만, 간신히 동작하는 프로그램을 '고치는 용도'로 사용해서는 절대 안 된다.

 

 

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

 

 

 

실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지도 않도록 하는 것이다. 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자.

실행 가능한 스레드 수를 적게 유지하는 주요 기법은 각 스레드가 무언가 유용한 작업을 완료한 후에는 다음 일거리가 생길 때까지 대기하도록 하는 것이다. 스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다.

 

 

 

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

 

공유 객체의 상태가 바뀔 때까지 쉬지 않고 검사해서는 안 된다는 뜻이다. 바쁜 대기는 스레드 스케줄러의 변덕에 취약할 뿐 아니라, 프로세서에 큰 부담을 주어 다른 유용한 작업이 실행될 기회를 박탈한다.

 

 

 

3. Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자.

증상이 어느 정도는 호전될 수도 있지만 이식성을 그렇지 않을 것이다. 처음 JVM에서는 성능을 높여준 yield가 두 번째 JVM에서는 아무런 효과가 없고, 세 번째에서는 오히려 느려지게 할 수도 있다. Thread.yield는 테스트 수단도 없다. 차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치해주자.

이런 상황에서 스레드 우선순의를 조절하는 방법도 있지만, 역시 비슷한 위험이 따른다. 스레드 몇 개의 우선순위를 조율해서 애플리케이션의 반응 속도를 높이는 것도 일견 타당할 수 있으나, 정말 그래야 할 상황은 드물고 이식성이 떨어진다.