CPU Process Thread Scheduling
3줄 요약
- CPU는 실제 명령을 실행하는 자원이고 process와 thread는 OS가 CPU에 올리는 실행 단위다.
- Java 요청 처리는 대부분 thread 단위로 관찰되며, thread 수와 runnable 상태는 CPU 병목 판단의 핵심 신호다.
- Scheduling과 context switch 비용을 모르면 thread를 늘리는 해결책이 오히려 지연을 키울 수 있다.
핵심 정리
- CPU core는 동시에 실행할 수 있는 작업 수의 상한을 만들고, OS scheduler는 runnable task를 core에 배분한다.
- Process는 독립된 주소 공간을 갖고, thread는 같은 process 안에서 heap과 file descriptor를 공유한다.
- Context switch는 실행 주체를 바꾸는 비용이며, thread가 많고 blocking이 잦을수록 증가한다.
- Java Thread는 OS thread와 연결되는 실행 단위로 보고, ExecutorService는 thread 생성과 queue 정책을 관리하는 장치로 본다.
- Thread dump는 Java thread가 RUNNABLE, BLOCKED, WAITING, TIMED_WAITING 중 어디에 머무는지 보여 주는 핵심 증거다.
헷갈리는 지점
- Thread가 많으면 처리량이 항상 늘어난다고 보기 쉽다.
- CPU core보다 runnable thread가 지나치게 많으면 scheduling 대기와 context switch가 증가한다.
- Blocking I/O를 처리하려면 thread가 필요하지만 계산 작업은 core 수가 상한이다.
- RUNNABLE은 항상 CPU를 쓰는 상태라고 오해하기 쉽다.
- Java thread dump의 RUNNABLE은 native I/O 대기까지 포함할 수 있다.
- OS의 per-thread CPU와 stack trace를 함께 봐야 한다.
- Process와 thread 차이를 문법 용어로만 외우기 쉽다.
- 운영에서는 주소 공간, 자원 공유, crash 영향, file descriptor 공유가 더 중요하다.
- Thread 문제는 process 전체 장애로 이어질 수 있다.
확인 질문
- CPU core와 Java thread 수는 어떤 관계인가?
- Thread는 실행 후보이고 core는 실제 실행 자원이라 runnable thread가 core보다 많으면 대기와 전환 비용이 생긴다.
- Process와 thread의 가장 중요한 차이는 무엇인가?
- Process는 독립 주소 공간을 갖고 thread는 같은 process 안에서 memory와 file descriptor를 공유한다.
- Thread dump로 가장 먼저 볼 것은 무엇인가?
- 많은 thread가 어떤 state와 stack trace에 몰려 있는지, 특정 lock이나 I/O 지점에 정체되어 있는지다.