여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 결정하는데, 구체적 스케줄링 정책은 운영체제마다 다를 수 있다. 따라서 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램은 다른 플랫폼에 이식이 어렵다.
이식성이 좋은 프로그램을 작성하는 방법
실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하자
실행 준비가 된 스레드는 맡은 작업을 완료할 때까지 계속 실행되도록 만들어야한다. 이렇게 한다면 os의 스레드 스케줄링 정책이 상이한 시스템에서도 동작이 크기 달라지지 않는다. 단, 여기서 알아야할 점은 전체 스레드 수와 실행 가능한 스레드 수는 다르다. 전체 스레드 수는 훨씬 많을 수 있고 대기 중인 스레드는 실행 가능하지 않으니까. (전체 스레드 수 = 실행 가능하지 않은 대기중인 스레드 수 + 실행 가능한(실행중인) 스레드 수)
기존의 자바 3전까지 java는 green thread 방식을 이용했다. kernel thread 1개가 이 JVM에 매핑되고 JVM 내부적으로 자바 라이브러리가 user-threads를 매핑하는 ManyToOne 모델이다. 이 방식의 단점은 하나의 커널 스레드가 내부적으로 여러가지 스레드를 수행할 수 없다는 것. 그렇다면 자연스럽게 user thread 들은 block이 생기게 된다. 아래 그림을 참조하자.
3 이후부터는 Native Thread 방식으로 바뀌게 되었는데 여러 개의 커널 스레드와 여러 개의 유저 스레드를 매핑하는, 즉 ManyToMany 방식으로 바뀌었다는 뜻이다. 이렇게 되었으니 스레드 스케줄링은 OS가 가지고 가게 되고, 내부적으로 유저 스레드를 통해서 각 스레드들을 관리하는 것이다.
그래서 나는 OS마다 JVM에 주는 커널 개수나 실행 시간이 다를 것이고, 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많지 않다면 OS마다 공정성이나 스레드의 개수가 크게 달라지지 않을 것이라고 이해하였다.( 라고 결론짓긴 했지만 잘못된 부분 말씀해주시면 감사하겠습니다 🙏🏻)
유저스레드, 커널스레드, java thread 등의 참조
실행 가능한 스레드 수를 적게 유지하는 기법
각 스레드가 task 완료 후 다음 task가 생길 때까지 대기하자. 스레드는 당작 처리할 작업이 없다면 실행되선 안된다.
실행자 프레임워크 ex) 스레드 풀 크기를 적절히 설정하고 작업은 짧게 유지, 단 너무 짧으면 작업 분배 부담이 오히려 성능을 떨어뜨림
스레드는 절대 바쁜 대기(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--;
}
}
래치를 기다리는 스레드를 1,000개 만들어 자바의 실제 CountDownLatch와 비교했을 때 이 클래스는 10배 정도 느리다고 한다. 이 클래스는 countdown과 await 모두 synchronized 메소드나 블록을 사용하며 스레드들을 '대기'상태가 아닌 '실행대기(조건이 충족되면 바로 실행할 수 있는)' 상태로 유지하는 것이다. 이렇게 하나 이상의 스레드가 필요도 없이 실행 가능한 상태 시스템은 성능과 이식성이 떨어진다.
이식성이 나쁜 특성
Thread.yield 사용
특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해 간신히 돌아가더라도, Thread.yield를 써서 문제를 해결하지 말자.
증상이 호전될 순 있지만 이식성은 그렇지 않다.JVM 버전이나 종류에 따라서 성능의 차이가 존재해 오히려 느려질 수도 있다.
Thread.yield는 테스트할 수단도 없으니 차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치하자.
스레드 우선순위 조절
스레드 우선순위를 조절할 수도 있지만, yield 사용 때와 비슷한 위험이 있다. 스레드 우선순위는 자바에서 이식성이 가장 나쁜 특성이다.
스레드 몇 개 우선순위 조율해서 애플리케이션 반응 속도를 높일수도 있지만 그래야할 상황은 드물고 이식성도 떨어진다.
심각한 응답 불가 상태는 진짜 원인을 찾아 수정하기 전까지 같은 문제가 반복해서 터질 것이다.
정리
- 프로그램 동작을 os의 스레드 스케줄러에 기대지 말자. 견고성, 이식성을 모두 해친다.
- Thread.yield나 스레드 우선순위에 의존하지 말자. 이 기능들은 스레드 스케줄러에 제공하는 힌트일 뿐이다.
- 스레드 우선순위는 이미 잘 동작하는 프로그램 서비스 품질 향상에 드물게 쓰이지만 겨우 동작하는 프로그램을 고치는 용도가 아니다.
* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.
'Reading > Effective Java' 카테고리의 다른 글
| [Effective-Java] Item 83. 지연 초기화는 신중히 사용하라 (0) | 2022.01.05 |
|---|---|
| [Effective-Java] Item 82. 스레드 안전성 수준을 문서화하라 (0) | 2022.01.05 |
| [Effective-Java] Item 81. wait와 notify보다는 동시성 유틸리티를 애용하라 (0) | 2022.01.05 |
| [Effective-Java] Item 80. 스레드보다는 실행자, 태스크, 스트림을 애용하라 (0) | 2022.01.05 |
| [Effective-Java] Item 79. 과도한 동기화는 피하라 (1) | 2022.01.05 |
