프로세스(Process)와 스레드(Thread)의 개념
컴퓨터 운영체제에 대한 내용을 학습하기 시작하면 가장 먼저 마주하는 개념이 바로 프로세스와 스레드이며, 또 그만큼 중요하게 여겨지는 개념이 바로 이들이다. 우선 이 둘이 어떻게 정의되는지를 확인하고 자세한 내용으로 넘어가 보자.
| 프로세스(Process) | 스레드(Thread) |
|---|---|
| 운영체제로부터 자원을 할당받은 작업의 단위 | 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위 |
프로그램(Program)과 프로세스
프로그램은 윈도우의 .exe 파일 등과 같이 '컴퓨터에서 실행할 수 있는 파일'을 통칭하며, 이들은 Java나 C언어 등과 같은 코드로 이루어져 있다.
아직 파일을 실행하지 않은 프로그램을 '정적 프로그램(Static program)'이라 하는데, 일반적으로는 이를 줄여서 '프로그램'으로 통칭한다.
그리고 이러한 프로그램이 실행되어 동적인 프로그램으로 변하면, 즉 프로그램이 돌아가고 있는 상태가 되면 그것을 바로 '프로세스'라 한다. 즉, 프로세스는 컴퓨터에서 작업 중인 프로그램을 의미한다. 여기서 '실행 중'이라는 것은 컴퓨터 메모리에 올라가 OS로부터 시스템 자원(CPU 등)을 할당받은 상태임을 의미한다.
따라서 프로그램과 프로세스는 다음과 같이 구분할 수 있다.
| 프로그램 | 프로세스 |
|---|---|
| 어떤 작업을 하기 위해 실행할 수 있는 파일 | 어떤 작업을 하기 위해 실행되어 작업 중인 프로그램 |
| 파일이 보조기억장치에는 있지만 메모리(주기억장치)에는 올라가 있지 않은 정적인 상태 | 프로그램이 메모리에 적재되어 CPU 자원을 할당받고 코드가 실행되고 있는 동적 상태 |
프로세스와 스레드
이전에는 프로그램을 실행하면 그 프로그램이 시작되어 종료될 때까지 프로세스 하나만을 사용해서 코드를 실행했다. 그러나 프로그램이 점차 복잡해지면서 프로세스 하나만으로 프로그램을 실행하는 것에 한계가 발생하였다.
그렇다면 '하나의 프로그램을 처리하기 위한 프로세스를 여러 개 만들면 되지 않을까?' 그러나 이는 불가능하다. OS는 안전성을 위해 각 프로세스마다 자신에게 할당된 메모리 내의 정보에만 접근할 수 있도록 하고 있으며, 이를 벗어난 정보에 접근하려 하면 에러를 발생시킨다. 따라서 프로세스와는 다른, 더 작은 실행 단위의 개념이 필요하게 되었으며, 이것이 바로 스레드이다.
스레드는 '하나의 프로세스 내에서 동시에 진행되는 작업의 단위'를 말한다. 예를 들어 크롬 브라우저라는 '프로그램'을 실행시켜 '프로세스'로 만들면, 우리는 이를 이용해 검색을 하면서 동시에 어떤 파일을 다운받기도 한다. 이러한 작업 단위 하나하나(검색, 다운로드)를 스레드라 하며, 앞서 말했듯 프로세스가 코드로 이루어진 덩어리라면, 스레드는 그 코드 내에 선언된 함수라고 할 수 있을 것이다.
일반적으로 하나의 프로그램은 하나 이상의 프로세스를 가지고 있으며, 하나의 프로세스는 반드시 하나 이상의 스레드를 갖는다.
프로세스와 스레드의 메모리
프로세스의 자원 구조
프로그램이 실행되어 프로세스가 만들어지면 앞서 메모리 구조 포스팅에서 보았던 4가지의 메모리 영역(코드 영역, 데이터 영역, 스택 영역, 힙 영역)을 할당받게 된다.
각 영역에 대한 자세한 설명은 상기 포스팅을 참고하자.
스레드의 자원 공유
스레드는 프로세스가 할당받은 자원을 이용하는 '실행의 단위'로서, 우리가 검색과 파일 다운로드를 동시에 할 수 있는 것도 스레드가 여러 개 존재하기 때문이다. 스레드들이 프로세스의 자원을 공유하면서 프로세스 실행 흐름의 일부가 되기 때문에 이것이 가능한 것이다. 즉, 프로세스 내에 여러 개의 스레드가 들어 있는 형태가 된다.
이때 스레드는 프로세스의 메모리 영역 중 Stack만을 복사하여 사용하고, 나머지 Code, Data, Heap 영역은 프로세스 내의 다른 스레드들과 공유한다.
앞선 포스트에서 설명했듯, Stack은 함수 호출 시 사용되는 지역변수 및 매개변수 등이 저장되는 공간으로, 독립적인 스택을 가졌다는 것은 독립적인 함수 호출이 가능하다는 의미이다. 그리고 독립적인 함수 호출이 가능하다는 것은 독립적인 실행 흐름이 추가된다는 말이다. 즉, 스레드가 독립적인 실행 흐름을 가질 수 있는 것은 Stack을 가지고 있기 때문이다.
참고로 프로세스 간의 자원 공유도 IPC(Inter-Process Communication) 혹은 LPC(Local inter-Process Communication) 등을 이용하거나 별도의 공유 메모리를 만드는 방법 등을 통해 가능하게 할 수 있다. 그러나 이는 메모리와 CPU 사이의 캐시 메모리까지 초기화하는 등 자원 부담이 크기 때문에 다중 작업 시에는 스레드를 이용하는 것이 훨씬 효율적이다. 따라서 현대 컴퓨터의 OS에서는 다중 프로세싱도 지원하기는 하지만 기본적으로는 다중 스레딩을 이용하고 있다.
프로세스와 스레드의 동시 실행 원리
멀티 코어와 스레드
CPU 하나는 여러 개의 코어를 가질 수 있다. 이때 코어는 말 그대로 CPU의 코어 유닛으로, 메모리에서 명령어를 가져와 해석하고 실행하는 유닛을 말한다. 이처럼 코어가 물리적인 개념이라면, 스레드는 논리적인 코어 개수를 말한다. 4코어 8스레드의 CPU가 있다고 생각해 보자. 이 CPU는 물리적으로는 4개의 코어를 가지고 있으며 각 코어는 2개의 스레드를 실행할 수 있다. 즉, OS가 8개의 작업을 동시에 처리할 수 있게 된다.
단, 여기서 말하는 스레드는 프로세스의 스레드와는 조금 다른 개념이다. 엄밀히는 CPU의 스레드는 하드웨어적 스레드로, 프로세스의 스레드는 소프트웨어적 스레드로 구분한다.
그런데 우리는 컴퓨터를 이용할 때 적어도 8개보다는 많은 프로그램을 동시에 켜 놓고 이용한다. 그 많은 프로그램을 한정된 논리적 스레드가 어떻게 처리할 수 있을까?
이를 이해하기 위해선 병렬성(Parallelism)과 동시성(Concurrency)이라는 개념을 이해해야 한다.
CPU의 작업 처리 방식
- 병렬성
- 코어의 수에 맞추어 여러 개의 프로세스와 스레드를 돌려 작업을 동시에(병렬로) 수행하는 것
- 듀얼코어, 쿼드코어 등의 명칭이 붙는 멀티코어 CPU에서 가능한 방식
- 동시성
- 둘 이상의 작업이 동시에 실행되는 것. 단, 실제 물리적으로 동시에 실행되는 것이 아니라, '동시에 실행되는 것처럼' 보이도록 하는 방식
- 코어가 처리해야 할 작업이 여러 개일 때, 이를 순차적으로 처리하는 것이 아니라 각 프로세스를 번갈아 가며 조금씩 처리함으로써 프로세스들이 동시에 실행되는 것처럼 보이도록 한다.
- 이렇게 진행 중인 작업을 번갈아 바꾸는 것을 Context Switching이라 한다.
여기서 '동시성'에 대해 한 번 더 생각해보자면, 사실 동시성은 '실제로 동시에 돌아가는 것'은 아니고 일종의 눈속임과 같다. 그러나 이렇게 번거롭게(작업들을 스위칭하면서까지) 진행하는 것은 몇 가지 이유가 있다.
첫 번째는 하드웨어적 한계이다. CPU의 성능을 높이는 것에도, 코어의 수를 늘리는 것에도 물리적인 한계가 존재한다. 따라서 수십, 수백 개의 프로세스를 실행하려면 결국 동시성이 필요한 것이다.
그리고 두 번째는 논리적인 효율성이다. 만약 2코어 4스레드의 작업에서 현재 8개의 작업이 있다고 가정하고, 그중 4개는 시간이 오래 걸리는 작업, 4개는 짧은 시간을 요하는 간단한 작업이라고 해 보자. 4스레드이므로 4개의 작업을 동시에 진행할 수 있을 텐데, 하필이면 시간이 오래 걸리는 4개의 작업부터 실행하기 시작했다면 간단한 4개의 작업은 본래 시간이 오래 걸리는 작업이 아닌데도 불구하고 앞서 처리 중인 4개의 작업이 끝날 때까지 무작정 기다려야 하는 것이다. 즉, 불필요한 대기 시간이 발생한다. 이러한 비효율을 극복하기 위해 작업을 잘게 나누어 번갈아 처리하는 동시성 개념을 채택한 것이다.
프로세스와 스레드의 생명 주기
프로세스와 스레드는 각자의 '생명 주기'를 가지고 있으며, OS는 이를 관리하고 프로세스와 스레드를 조정함으로써 시스템의 자원을 효율적으로 사용하도록 한다.
프로세스 스케줄링(Process scheduling)
- 운영체제에서 CPU를 사용할 프로세스를 선택하고 CPU의 자원을 할당하는 것
- 프로세스 스케줄링을 통해 각 프로세스를 우선순위, 작업량 등을 고려하여 배치하며, 따라서 멀티태스킹 작업의 핵심적인 요소가 된다.
- 운영체제의 특징 및 시스템 요구사항에 따라 FCFS(First-Come, First-Served), SJF(Shortest-Job-First), Priority, RR(Round-Robin), Multilevel Queue 등 다양한 알고리즘으로 동작
프로세스 상태
-
프로세스가 실행되는 동안 변경되는 고유의 상태
-
일반적으로 다음과 같은 5가지 상태를 가짐
상태 내용 생성(New) 프로세스가 생성되었으나 아직 준비되지 않은 상태 준비(Ready) 프로세스가 실행되기 위해 기다리는 상태
CPU를 할당받을 수 있는 상태이며, 언제든지 실행 가능한 상태실행(Running) 프로세스가 CPU 자원을 할당받아 실행되는 상태 대기(Waiting) 프로세스에 특정 이벤트(입출력 요청 등)가 발생하여 대기하는 상태
CPU를 할당받지 못하며, 이벤트가 해결되어 다시 준비 상태로 전환될 때까지 대기함종료(Terminated) 프로세스가 실행을 완료하고 종료된 상태
더 이상 실행될 수 없으며, 메모리에서 제거됨
프로세스 상태 전이
프로세스가 실행되는 동안 상태가 OS에 의해 변경되는 것
| 구분 | 내용 |
|---|---|
| Admitted(New → Ready) | 프로세스 생성을 승인받음 |
| Dispatch(Ready → Running) | 준비 상태에 있는 여러 프로세스(준비 리스트) 중 실행될 프로세스를 선정(Scheduling)하여 CPU를 할당(Dispatching) 문맥 교환(Context switching) 발생 |
| Interrupt(Running → Ready) | Timeout 혹은 예기치 않은 이벤트가 발생하여 현재 실행 중인 프로세스를 준비 상태로 전환하고, 해당 작업을 먼저 처리 |
| I/O or event wait(Running → Wainting) | 실행 중인 프로세스가 입출력이나 이벤트를 처리해야 하는 경우, 입출력이나 이벤트가 끝날 때까지 대기 상태로 전환 |
| I/O or event completion(Waiting → Ready) | 입출력이나 이벤트가 모두 끝난 프로세스를 다시 준비 상태로 만들어 스케줄러에 의해 선택될 수 있는 상태로 전환 |
프로세스 컨택스트 스위칭(Context Switching)
앞서 짧게 설명했듯, 컨택스트 스위칭은 CPU가 한 프로세스에서 다른 프로세스로 전환할 때 발생하는 일련의 과정을 말한다. 동작 중인 프로세스가 대기하면서 해당 프로세스의 상태(Context)를 보관하고, 대기하던 다음 순서의 프로세스가 동작하면서 이전에 보관했던 상태를 복구하는 작업을 말한다.
이 컨택스트 스위칭은 스케줄러에 의해 일어나며, '다음에 동작할 프로세스'를 스케줄러가 결정하게 된다.
-
프로세스 제어 블록(Process Control Block, PCB)
PCB는 컨택스트 스위칭이 일어날 때 OS에서 프로세스를 관리하기 위해 해당 프로세스의 상태(Context) 정보를 보관하는 자료 구조를 말한다. 즉, 프로세스 스케줄링을 위한 임시 저장소와 같다.
OS에 따라 약간의 차이가 있을 수 있지만, 일반적으로 다음과 같은 정보가 포함된다.구분 내용 포인터(Pointer) 프로세스의 현재 위치를 저장하는 포인터 정보 프로세스 상태(Process state) 프로세스의 각 상태 - 생성(New), 준비(Ready), 실행(Running), 대기(Waiting), 종료(Terminated) - 를 저장 프로세스 아이디(Process ID, PID) 프로세스 식별자를 지정하는 고유한 ID 프로그램 카운터(Program counter) 프로세스를 위해 실행될 다음 명령어의 주소를 포함하는 카운터를 저장 레지스터(Register) 누산기, 베이스, 레지스터 및 범용 레지스터를 포함하는 CPU 레지스터 내의 정보 메모리 제한(Memory Limits) 운영 체제에서 사용하는 메모리 관리 시스템에 대한 정보 열린 파일 목록(List of open file) 프로세스를 위해 열린 파일의 목록
-
컨택스트 스위칭 과정
두 프로세스 간 스위칭 과정은 다음과 같이 정리할 수 있다.
순서 동작 1 CPU는 Process P1을 실행(Executing) 2 일정 시간이 지나 Interrupt 또는 system call이 발생(CPU는 대기 상태) 3 현재 실행 중인 Process P1의 상태를 PCB1에 저장(Save state into PCB1) 4 다음으로 실행할 Process P2를 선택(CPU 스케줄링) 5 Process P2의 상태를 PCB2에서 로드(Reload state from PCB2) 6 CPU가 Process P2를 실행(Executing) 7 일정 시간이 지나 Interrupt 또는 system call이 발생(CPU는 대기 상태) 8 현재 실행 중인 Process P2의 상태를 PCB2에 저장(Save state into PCB2) 9 다시 Process P1을 실행하기 위해(CPU 스케줄링) Process P1의 상태를 PCB1에서 로드(Reload state from PCB1) 10 CPU는 Process P1을 중단된 시점부터 실행(Executing)
-
Context switching overhead
컨택스트 스위칭은 빠른 반응성과 동시성을 제공하나, 시스템에 많은 부담을 주게 된다. 앞서 살펴본 컨택스트 스위칭 과정에서 P1이 대기 상태가 될 때 P2가 바로 실행되지 않고 잠시 대기 상태에 있다가 실행되는 것을 볼 수 있는데, 이 간극이 바로 스위칭 오버헤드이다.
컨택스트 스위칭 오버헤드는 주로 PCB 저장 및 복원 비용, CPU 캐시 메모리 무효화에 따른 비용, 프로세스 스케줄링 비용 등으로 인해 발생한다.
스레드 스케줄링
- 프로세스 스케줄링과 마찬가지로 OS에서 다중 그레드를 관리하며 CPU를 사용할 스레드를 선택하고 자원을 할당하는 작업을 의미
- 기본적인 알고리즘은 프로세스 스케줄링 알고리즘과 유사하다.
- 하나의 프로세스 내에서 다수의 프로세스가 동작하는 형태이므로 스레드 간 상호작용 및 동기화 문제를 고려해야 한다는 차이점이 있다.
스레드 상태
-
프로세스와 마찬가지로 상태가 존재한다.
-
일반적으로 다음 4가지 상태를 가진다.
상태 설명 New 스레드가 생성되고 아직 호출되지 않은 상태 Runnable 스레드가 실행되기 위해 대기하는 상태
CPU 자원을 할당받을 수 있는 상태로 언제든 실행 가능Blocked 스레드에 특정 이벤트(입출력 요청 등)가 발생하여 대기하는 상태
CPU 자원을 할당받지 못하며, 이벤트가 해결되어 다시 Runnable 상태로 전환될 때까지 대기Terminated 스레드가 실행을 완료하고 종료된 상태
더 이상 실행될 수 없으며, 메모리에서 제거됨
스레드 컨택스트 스위칭
- 스레드 제어 블록(Thread Control Block, TCB)
PCB 안에 들어 있는 자료 구조로, 스레드의 상태 정보와 ID, 우선순위, 스케줄링 정보 등 다양한 정보를 저장한다.
또한 스레드 간의 자원 공유 및 동기화도 TCB를 통해 관리된다.
멀티 프로세스(Multi process)와 멀티 스레드(Multi thread)
멀티 프로세스
하나의 응용 프로그램을 여러 개의 프로세스로 구성하여 프로세스들이 하나의 작업(프로그램)을 처리하도록 하는 것을 말한다.
| 구분 | 내용 |
|---|---|
| 장점 | 자식 프로세스 중 하나에 문제가 생겨도 다른 프로세스에 영향을 미치지 않는다. |
| 단점 | 컨택스트 스위칭 과정에서의 오버헤드가 발생할 수 있다. 프로세스 사이의 변수를 공유할 수 없으며, 공유를 위해선 복잡하고 비효율적인 통신 기법을 사용해야 한다(앞서 언급한 IPC 등). |
멀티 스레드
하나의 응용 프로그램을 여러 개의 스레드로 구성하여 하나의 프로세스 안에 여러 개의 스레드가 있는 것을 말한다. 따라서 하나의 프로그램에서 두 가지 이상의 동작을 동시에 처리하는 것이 가능해진다.
| 구분 | 내용 |
|---|---|
| 장점 | 프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어 자원의 효율적 관리가 가능하다. 스레드 간 데이터를 주고받는 것이 간단하므로 시스템 자원 소모가 줄어들고, 컨택스트 스위칭도 빠르게 이루어져 처리량이 증가한다. 스레드는 Stack 영역을 제외한 나머지 프로세스의 메모리 영역을 공유하므로 통신의 부담이 적다 |
| 단점 | 설계가 복잡하여 주의 깊은 설계가 필요하며 디버깅 역시 까다롭다. 단일 프로세스 시스템에서는 효과를 기대하기 어렵다. 하나의 스레드에 문제가 발생하면 전체 프로세스가 영향을 받는다. |
WAS와 스레드 풀(Thread pool)
WAS
앞서 WAS 포스트에 WAS와 관련된 대략적인 내용을 정리해 두었으므로 간단히만 설명하면 정적 리소스를 처리하는 웹 서버(Web-server)와 달리 내부의 애플리케이션 로직을 수행하고 동적인 리소스를 처리하는 서버를 웹 애플리케이션 서버(Web Application Server), 줄여서 WAS라 한다.
그리고 마찬가지로 앞서 설명했지만, WAS는 웹 서버와 서블릿 컨테이너(Sevlet container)로 구성되어 있다. 여기서 서블릿 컨테이너는 서블릿을 지원하는 WAS를 말하는 것이다. 따라서, 웹에서의 멀티 스레드와 스레드 풀을 이해하려면 서블릿에 대해 이해하는 것부터 시작해야 할 것이다.
서블릿(Sevlet)
서블릿을 한 줄로 정의하면 “클라이언트의 요청을 처리하고 그 결과를 반환하는 Sevlet 클래스의 구현 규칙을 준수하는 자바 웹 프로그래밍 기술”이라고 할 수 있다. 서블릿은 HTTP 형태로 전송받은 데이터에 대해 헤더와 페이로드로 분리하거나(파싱) 송신할 데이터를 HTTP 헤더로 캡슐화하거나, 또는 데이터를 주고받기 위해 소켓 연결을 하는 등 다양한 작업들을 수행한다.
대략적인 서블릿 컨테이너의 동작 과정은 다음과 같다.
- 클라이언트가 URL을 입력하면 HTTP가 웹 서버를 거쳐 서블릿 컨테이너로 전송된다.
- 요청을 전달받은 서블릿 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성한ㄷ.
- web.xml을 기반으로 하여 클라이언트가 요청한 URL이 어느 서블릿에 대한 요청인지 확인한다.
- 해당 서블릿에서 service 메서드를 호출한 후 클라이언트의 요청 메서드(GET or POST)에 따라 doGet() 혹은 doPost()를 호출한다.
- 호출된 메서드는 각 기능에 따른 동적 페이지를 생성한 후 HttpServletResponse 객체에 전달하고 서블릿 컨테이너는 클라이언트에 응답을 보낸다.
- 응답이 완료되면 서블릿 컨테이너는 앞서 생성한 두 객체(HttpServletRequest, HttpServletResponse)를 소멸시킨다.
멀티 스레드
스레드 풀에 대해 이해하기에 앞서 멀티 스레드에 대해 다시 짚어보자. 프로그램이 메인 메모리에 적재되어 프로세스로 변환되면 해당 프로세스가 실제 작업을 수행하기 위해 생성하는 작업 단위가 스레드이며, 이때 스레드는 하나의 동작만을 수행한다.
워드 프로세서를 생각해 보자. 워드 프로세서라는 프로그램이 메모리에 적재되어 프로세스로 변환되면(간단히 말해 프로그램을 실행하면) 해당 프로세서는 사용자의 입력을 받는 기능, 사용자의 입력을 화면에 출력하는 기능, 주기적으로 파일을 저장하는 기능 등 다양한 기능을 수행해야 하며, 대부분의 기능은 다른 기능들과 동시에 수행되어야 할 것이다(사용자의 입력을 전부 다 받고 나서야 화면에 해당 입력 사항이 나타나는 워드 프로세서...생각만 해도 끔찍하다). 이처럼 동시에 여러 개의 작업을 진행하기 위해 나타난 개념이 바로 멀티 스레드이다.
멀티 스레드가 어떤 개념인지 기억했다면 다시 WAS로 돌아오자. WAS 역시 다양한 요청에 대해 작업을 수행해야 하며, 해당 요청을 순차적으로 수행한다면 전체 작업 속도 및 효율성이 상당히 저하될 것이다. 따라서 WAS 역시 멀티 스레드를 지원하며, 서버는 각 요청마다 스레드를 할당하고, 각 스레드는 서블릿 객체를 활용해 각 요청에 대해 적절한 응답을 보내는 것이다.
스레드 풀(Thread pool)
그런데, 어떤 요청이 들어올 때마다 스레드를 생성할 경우 여러 가지 문제가 발생한다. 우선 스레드 생성에 시간이 필요하므로 응답 시간도 늦어질 것이며, 스레드의 문맥 교환(Context switching)으로 인한 비용(CPU 자원 사용)이 발생한다. 게다가 요청이 증가하여 CPU나 메모리의 한계치를 넘어설 경우 서버 자체가 죽어버리는 사고가 발생할 수도 있다. 총 스레드 개수를 제한하여 서버 다운을 방지하더라도, 새로운 스레드를 생성하기 위해서는 기존의 스레드를 강제로 종료해야 하므로 스레드 간에 서로가 메모리에 접근하기 위해 서로를 쫓아내는 데드 락(Dead lock)과 같은 상황이 발생할 수도 있다.
이러한 문제를 해결하기 위해 도입된 개념이 스레드 풀(Thread pool)이다. 스레드 풀은 간단히 비유하면 식당의 테이블과 같은 것이다. 식당에 준비된 테이블이 손님으로 가득 차면 다음 손님은 가게 밖에서 기다리다가 테이블이 비면 해당 테이블에 앉아 음식을 주문한다.
마찬가지로 스레드 풀은 요청마다 스레드를 만드는 대신(식당으로 치면 손님이 올 때마다 테이블을 새로 가져오는 대신) Pool 안에 미리 정해진 수의 스레드를 만들어 놓고 클라이언트의 요청이 오면 스레드 풀에 현재 작업이 할당되지 않은 스레드를 요청한다. 그리고 작업을 완료하면 해당 스레드를 다시 스레드 풀에 반환한다. 만약 스레드를 요청했을 때 놀고 있는 스레드가 없다면? 다른 요청이 종료되어 스레드가 반납될 때까지 대기하게 된다(이때 스레드 할당을 기다리는 요청은 작업 큐에 대기한다).
이처럼 스레드 풀을 사용할 경우, 미리 스레드가 생성되어 있으므로 스레드의 생성 및 종료에 사용되는 비용을 절약할 수 있으며 반응 속도 역시 향상된다. 게다가 데드 락이나 서버 셧다운 등의 위험도 방지할 수 있다.
WAS에서 중요한 것은 스레드 풀의 크기(pool 내 스레드의 개수)이다. 스레드 풀이 너무 작을 경우 동시 처리 가능한 요청의 수도 작아지므로 대기하는 클라이언트가 많아진다(대기 시간도 길어질 것이다). 그렇다고 크기를 무작정 키우면 서버 과부하가 발생할 수 있다. 따라서 서버 자원 및 서비스의 트래픽 등 여러 요인을 고려하여 스레드 풀의 크기를 결정해야 한다. AWS와 같이 필요한 스레드의 수만큼 서버를 증설하는 클라우드 서버 서비스의 경우에도 스레드 풀의 크기가 비용과 직결되므로 그 제한 등을 적절히 설정하여야 할 것이다.
참고 자료
