반응형
- 컨텍스트 스위칭 비용이 줄어든다.
요청마다 새 스레드를 만들면, 운영체제는 각 스레드마다 스택, 레지스터 상태, 메모리 정보 등을 관리해야 한다. 이게 많아지게 되면
- 커널이 레지스터와 메모리 상태 저장/복원하는데 오버헤드 발생
- 스레드 수가 많아질수록 CPU 캐시 미스 증가
- 스케줄러가 많은 스레드 중에서 어떤 걸 실행시킬지 결정하는 비용 증가
반면 스레드 풀은 제한된 개수의 스레드만을 재사용하기 때문에
- 스레드 수 자체가 제한됨 → 스위칭 횟수도 줄고, 캐시 효율도 올라감
- idle 상태의 스레드 재사용 → 새로 만들고 파괴하는 비용이 없음
- GC 부담이 낮음 - 스레드 객체는 GC 대상이기 때문에
- 예측 가능성
스레드 풀 방식은 제한된 리소스 내에서 동작해서 예측 가능성이 높지만 요청마다 스레드를 생성하는 방식은 요청 폭주 시 리소스 고갈 가능성이 높다.
- 성능 안정성 → 높음
- 부하 분산 실패 시 - 스레드 풀 방식은 큐에 대기 하며 요청이 지연되고 스레드 생성 방식은 OOM이 발생할 수 있다.
실제 자바 서블릿 컨테이너도 내부적으로 ThreadPoolExecutor를 사용해서 요청을 처리한다. 기본적으로 최대 스레드 수 제한, 큐 사이즈 제한 등을 걸어둬서 안정적으로 동작

반응형
'backend > spring' 카테고리의 다른 글
| [Spring]Spring 레거시 프로젝트 AWS elastic beanstalk으로 5분만에 배포하기 (1) | 2023.04.02 |
|---|---|
| [java] Hwplib 사용해보기 (3) | 2023.02.08 |