Multithreading Benefits
멀티 스레딩의 가장 중요한 이점은 아래와 같다.
- Better CPU utilization
- Simple program design in some situations
- More responsive programs
- More fair division of CPU resources between different tasks
Better CPU Utilization
로컬 파일 시스템에서 파일을 읽고 처리하는 응용 프로그램을 상상해봐라. 디스크에서 파일을 읽는데 5초가 걸리고 처리하는데 2초가 걸린다고 할 때, 두 개의 파일을 읽으면 총 14초가 소요된다.
디스크에서 파일을 읽을 때 대부분의 CPU 시간은 디스크가 데이터를 읽을 때까지 대기한다. 그 시간 동안 CPU는 거의 유휴 상태이다. 따라서 작업 순서를 변경하면 CPU를 더 잘 활용할 수 있다. 아래 작업 순서를 보자.
CPU는 첫 번째 파일을 읽을 때까지 기다린다. 그런 다음 두 번째 파일을 읽시 시작한다. 컴퓨터의 IO 구성 요소가 두 번째 파일을 읽는 동안 CPU는 첫 번째 파일을 처리한다. 디스크에서 파일을 읽을 때 까지 CPU는 대부분 유휴 상태이다. 일반적으로 CPU는 IO를 기다리는 동안 다른 작업을 수행할 수 있다. (디스크 IO 작업 뿐만 아니라 네트워크 IO, 머신의 사용자 입력 대기 등의 작업도 마찬가지) 네트워크 및 디스크 IO는 종종 CPU 및 메모리 IO보다 훨씬 느리다.
Simpler Program Design
단일 스레드 응용 프로그램에서 수동으로 위의 읽기 및 처리 순서를 프로그래밍 하려면 각 파일의 읽기 및 처리 상태를 모두 추적해야 한다. 하지만 각 단일 파일을 읽고 처리하는 두 개의 스레드를 시작한다면 그럴 필요가 없다. 디스크가 파일을 읽을 때까지 이러한 스레드는 각각 차단된다. 대기하는 동안 다른 스레드는 CPU를 사용하여 이미 읽은 파일 부분을 처리할 수 있다. 결과적으로 디스크는 항상 사용중이어서 다양한 파일에서 메모리로 읽는다. 이로 인해 디스크와 CPU를 보다 잘 활용할 수 있다. 각 스레드는 단일 파일만 추적하면되기 때문에 프로그래밍하기가 더 쉬워진다.
More Responsive Programs
단일 스레드 응용 프로그램을 다중 스레드 응용 프로그램으로 전환하는 또 다른 일반적인 목표는 보다 반응이 빠른 응용 프로그램을 만드는 것이다. 어떤 포트에서 들어오는 요청을 수신 대기하는 서버 응용 프로그램을 상상해 보아라. 요청이 수신되면 요청을 처리한 다음 listen 상태로 돌아간다. 서버 루프는 다음과 같다.
위와 같은 경우 요청을 처리하는데 시간이 오래 걸리면 새 클라이언트가 해당 기간 동안 서버에 요청을 보낼 수 없다. 서버가 listen하는 동안에만 요청을 수신할 수 있다. 이를 수정하는 방법은 listen 스레드가 요청을 worker 스레드(요청을 처리하는)로 전달하고 즉시 listen 상태로 돌아가는 것이다. worker 스레드는 요청을 처리하고 클라이언트에게 응답을 보낸다.
이렇게 하면 서버 스레드가 더 빨리 listen하게 된다. 따라서 더 많은 클라이언트가 서버에 요청을 보낼 수 있다. 서버의 응답성이 향상된다. 데스크톱 응용 프로그램에서도 마찬가지이다. 만약 단일 스레드라면 긴 작업을 시작하는 버튼을 클릭하고 작업을 실행하는 스레드가 창, 버튼 등을 업데이트하는 스레드인 경우 작업이 실행되는 동안 응용 프로그램이 응답하지 않은 것으로 나타난다. 하지만 각 작업간 thread를 multi로 나눈다면 worker 스레드가 작업을 수행하는 동안 창 스레드는 다른 사용자에게 자유롭게 응답할 수 있다. worker 스레드가 완료되면 창 스레드에게 신호를 보낸다. 그런 다음 창 스레드는 작업 결과로 응용 프로그램 창을 업데이트 할 수 있다. 스레드를 구분한 디자인이 사용자에게 보다 반응적인 프로그램이다.
More Fair Distribution of CPU Resources
클라이언트로부터 요청을 받는 서버를 상상해보아라. 그런 다음 클라이언트 중 하나가 처리하는데 시간이 오래 걸리는 요청(10초)을 보낸다고 가정해보자. 서버가 단일 스레드를 사용하여 모든 작업을 처리한 경우 처리 속도가 느린 요청 다음의 모든 요청은 전체 요청이 처리 될 때까지 대기해야 한다. 여러 스레드 간에 CPU 시간을 나누고 스레드 간에 전환함으로써 CPU는 여러 요청간에 실행 시간을 보다 공정하게 공유할 수 있다. 그런 다음 요청 중 하나가 느린 경우에도 처리 속도가 빠른 다른 요청을 느린 요청과 동시에 실행할 수 있다. 물론 이것은 느린 요청을 실행하는데 CPU가 단독으로 할당되지 않기 때문에 느린 요청을 실행하는 것이 훨씬 더 오래 걸린다는 것을 의미한다. 그러나 다른 요청은 처리되기 전에 느린 작업이 완료될 때까지 기다릴 필요가 없기 때문에 처리하기 위해 더 짧은 시간만을 기다리면 된다.
'JAVA > Concurrency' 카테고리의 다른 글
| # Java Concurrency In Practice - Chapter3 (0) | 2020.02.15 |
|---|---|
| # Java Concurrency In Practice - Chapter 2 (0) | 2020.02.13 |
| # Java Concurrency In Practice - Chapter 1 (0) | 2020.02.03 |
| # Java Concurrency and Multithreading Tutorial - Concurrency vs Parallelism (0) | 2020.01.31 |
| # Java Concurrency and Multithreading Tutorial (0) | 2019.12.30 |