정리: 이태혁 (Lee, Taehyuk)

<aside> 💬 참고사이트

1. https://syundev.tistory.com/270
2. https://pompitzz.github.io/blog/Java/threadPoolExecutor.html#executors-팩토리를-활용하여-threadpoolexecutor-생성하기
3. https://wellbell.tistory.com/237
4. https://projectreactor.io/docs/core/release/api/reactor/core/scheduler/Schedulers.html
5. https://wiki.terzeron.com/Programming/Java/Reactor_Flux의_publishOn_subscribeOn을_이용한_스케쥴링
6. https://velog.io/@jaehyunup/Srping-Webflux의-탄생-배경과-MVC와의-차이
7. https://dev-jj.tistory.com/entry/Spring-WebFlux-EventLoop-Non-Blocking
8. https://devahea.github.io/2019/04/21/Spring-WebFlux는-어떻게-적은-리소스로-많은-트래픽을-감당할까/
9. https://robin00q.tistory.com/83

</aside>

서론

Why Thread Pool?

• Process내부의 Thread(흐름)단위를 여러개 생성해서 병렬처리하는 경우들이 빈번하게 일어난다. 그러나, Thread가 필요할때마다 Process내부에서 새로운 Thread를 생성하고 종료하는 것 자체가 오버헤드가 발생한다. 이에 따라 미리 Thread들을 생성하여 풀로 관리하여 필요할때 사용함으로써 자원 효율성, 응답성 향상, 일관성, 스레드 생성 오버헤드 감소, 스레드 개수 제어 등의 효과를 볼수 있다.

<aside> 💡 Thread 생성 오버헤드란? 스레드 생성 시에는 스레드 스택, 스레드 ID, 레지스터 등의 자원이 할당되고 초기화되어야 한다. 이러한 작업은 메모리, CPU 시간 등의 자원을 사용하며, 이는 시스템의 전반적인 성능에 영향을 미친다.

</aside>

스레드풀이 만병 통치약? (No)

그림 출처: LinkedIn Thread Pool hell 현상 (사이트)

• Thread Pool Hell 현상 - API-Link에서 겪은 문제
  • 소켓과 같이 짧은 시간에 엄청난 속도로 트래픽이 몰리면 스레드가 모두 고갈된다. (스레드풀의 스레드 고갈 현상을 의미한다)
  • API - Link에서는 Event-Loop 패턴에서 기본적으로 제공되는 Netty Thread Pool이 위와 같은 Thread Pool Hell현상을 겪음.

본론

JAVA 에서의 스레드 풀 관리?

<aside> 💡 Java에서 사용 가능한 스레드 풀 (아래 3가지로 분류할수 있다)

 **1. 일반 자바 스레드 풀**,       **2. 스프링 제공 스-레드 풀**,       **3.** **WebFlux 제공 스레드풀**

</aside>

• 참고로 Netty서버를 위한 Thread-Pool이 존재하긴 하나, 이는 Event-Loop를 지원하거나 비동기적인 웹서버를 위한 Thread-pool이지 우리가 직접 접근할수 있는 Pool은 아니다.