원글 페이지 : 바로가기
여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다. 정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다. 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지돼서는 안된다. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. 스케줄링이란 메모리에 적재된 프로그램을 CPU가 실행할 수 있도록 운영체제로 하여금 프로세스나 스레드에 CPU를 할당하는 것으로 스케줄러는 제한된 자원을 여러 프로세스가 효율적으로 운영하도록 다양한 정책을 가지고 CPU를 할당하게 되는데, 정책이란 어떤 기준 / 순서로 CPU를 할당하는지 결정하는 방법이다. 스케줄러는 프로세스 선택 기준을 정하는 정책 부분과 선택된 프로세스에 CPU를 할당하는 디스패처로 구성되는데 결국 프로세스 스케줄링은 준비 큐의 프로세스 중 정책에 따라 하나의 프로세스를 선택하여 CPU를 할당하는 행위이다. 스레드 스케줄링도 스레드를 어떤 기준에 따라 순서대로 실행시키는 행위이다. 이 또한 운영체제가 작업을 모두 처리하는데 Java의 경우 JVM이 이를 대신 처리한다. https://docs.oracle.com/cd/E19455-01/806-3461/images/nancb8.eps.gif JVM의 스레드는 User-Level-Thread 이고 실제 실행시 Kernal-Level-Thread와 매핑된다. 이식성이 좋은 프로그램 작성 방법 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 한다. 그래야 스레드 스케줄러가 고민할 거리가 줄어든다. 실행 준비된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만든다. 이런 프로그램이라면 스레드 스케줄링 정책이 아주 상이한 시스템에서도 동작이 크게 달라지지 않는다. 여기서 실행 가능한 스레드의 수와 전체 스레드 수는 구분해야 한다. 전체 스레드 수는 훨씬 많을 수 있고, 대기중인 스레드는 실행 가능하지 않다. 실행 가능한 스레드 수를 적게 유지하는 기법 각 스레드가 무언가 유용한 작업 완료 후 다음 일거리가 생길 때 까지 대기한다. 스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다. 스레드 풀 크기를 적절히 설정하고 작업은 짧게 유지하면 된다. 단, 너무 짧으면 컨텍스트 스위치 오버헤드로 성능이 더 떨어질 수 있다. 스레드가 busy waiting 상태가 되지 않게 한다. 공유 객체의 상태가 바뀔 때 까지 쉬지않고 검사(무한 루프)해서는 안된다. busy waiting 상태는 스레드 스케줄러의 변덕에 취약할 뿐 아니라 프로세서에 큰 부담을 주어 다른 유용한 작업이 실행될 기회를 박탈한다. package item84;
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 coundDown() {
if (count != 0)
count--;
}
} 하나 이상의 스레드가 필요도 없이 실행 가능한 상태인 시스템은 흔하게 볼 수 있는데 이런 시스템은 성능과 이식성이 떨어질 수 있다. Thread.yield 사용 지양 JVM의 스레드 스케줄러에게 현재 스레드의 우선 순위를 낮춰도 된다는 힌트를 보내는 메서드이다. 스레드 스케줄러는 우선순위, 도착시간 두가지 기준으로 스케줄링 알고리즘을 구성하는데 현재 스레드의 작업 중요도가 낮다면 우선순위를 낮춰서 다른 작업에게 넘겨주고자 할때 yield를 사용한다. 특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌아가는 프로그램을 보더라도 Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자. 증상은 호전될 수도 있지만 이식성은 나쁘다. 처음 JVM에서 성능을 높여준 yield가 두번째 JVM에서는 아무 효과가 없고 세번째에서는 오히려 느려지게 할 수도 있다. Thread.yield는 테스트할 수단도 없다. 차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치해주자. 스레드 우선순위는 자바에서 이식성이 가장 나쁜 특성에 속한다. 심각한 응답 불가 문제를 스레드 우선순위로 해결하려는 시도는 절대 합리적이지 않다. 진짜 원인을 찾아 수정하기 전까지 같은 문제가 반복해서 터져 나올 것이다. 핵심정리 프로그램의 동작을 스레드 스케줄러에 기대지 말자. 견고성과 이식성을 모두 해치는 행위다. 같은 이유로, Tread.yield와 스레드 우선순위에 의존해서도 안 된다. 이 기능들은 스레드 스케줄러에 제공하는 힌트일 뿐이다. 스레드 우선순위는 이미 잘 동작하는 프로그램의 서비스 품질을 높이기 위해 드물게 쓰일 수는 있지만, 간신히 동작하는 프로그램을 '고치는 용도'로 사용해서는 절대 안된다. https://gengmi.tistory.com/entry/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C-%EC%8A%A4%EC%BC%80%EC%A4%84%EB%A7%81 [운영체제] 프로세스와 스레드 스케줄링 프로세스와 스레드 프로세스 Process - 작업의 단위 CPU가 처리하는 작업(Task)라고도 불리며, 실행중인 프로그램을 의미합니다. 구체적으로는, 디스크에 저장되어 있던 실행 가능한 프로그램이 메 gengmi.tistory.com https://velog.io/@semi-cloud/Java-%EC%95%84%EC%9D%B4%ED%85%9C-84-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8%EC%9D%98-%EB%8F%99%EC%9E%91%EC%9D%84-%EC%8A%A4%EB%A0%88%EB%93%9C-%EC%8A%A4%EC%BC%80%EC%A4%84%EB%9F%AC%EC%97%90-%EA%B8%B0%EB%8C%80%EC%A7%80-%EB%A7%88%EB%9D%BC [Effective Java] 아이템 84: 프로그램의 동작을 스레드 스케줄러에 기대지 마라 스케줄링 정책은 운영체제마다 다를 수 있으므로, 프로그램의 성능이 스케줄러에 따라 달라지지 않도록 해야 한다. 아래 세 가지 방안을 지킨다면, 스케줄러에 독립적인 이식성이 높은 프로그 velog.io https://agentsmith.tistory.com/59 [Effective Java] ITEM84 : 프로그램의 동작을 스레드 스케줄러에 기대지 말라 스레드 스케줄러와 Thread.yield, 스레드 우선순위에 의존하지 말자. 견고성과 이식성을 모두 해치는 행위이다. 스레드 우선순위는 프로그램의 서비스 품질을 높이는데 드물게 쓰일 수는 있지만 프 agentsmith.tistory.com https://jwkim96.tistory.com/318 [Effective Java] 아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라 0. 들어가며 이 아이템은 스레드 스케줄러에게 의존적인 코드를 작성하지 말라는 내용입니다. 아래에서 조금 더 자세히 알아보겠습니다. 1. 스레드 스케줄링 스레드 스케줄링은 간단히 말해서, jwkim96.tistory.com https://ktaes.tistory.com/90 [Effective-Java] Item 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 결정하는데, 구체적 스케줄링 정책은 운영체제마다 다를 수 있다. 따라서 정확성이나 성능이 스 ktaes.tistory.com