thread pool을 알아야 문제가 발생했을 때 트러블 슈팅을 할 수 있을 것이다. 어떤 원리로 돌아가는지 아는 것이 트러블 슈팅의 첫걸음 🥾
Thread의 create(속도 저하의 원인)을 줄이기 위해서 thread 들을 모아놓고 job이 도착하면 idle 한 thread를 가져다 쓰는 것
Thread Pool의 성능에서 가장 중요한 것은 pool size
pool size가 너무 크면 오히려 성능이 떨어지기도 한다. -> 실험을 통해서 시간을 비교해야 적당한 size를 구할 수 있다.
보통은 cpu bound job의 개수만큼 cpu를 사용하는 것이 가장 효과적. 하지만 IO bound job의 개수가 많아질수록 고르기 어려워진다.
너무 작으면 (1이라면) 작업들이 도착했을 때 max pool size가 될 때까지 thread create가 발생
-> thread pool을 사용할 이유가 사라짐
너무 커지면 메모리 측면에서 낭비
ThreadPoolExecutor는 항상 큐를 가지고 있다. 그리고 그 큐의 종류에 따라 3가지로 나눌 수 있다.
ThreadPoolExecutor의 생성자, queue를 입력받는다.
버퍼 공간이 없는 큐. max pool size 만큼 작업 가능. idle한 thread가 남아있지 않을 경우 job이 거부된다.
무제한 큐(LinkedList로 구현). max pool size는 의미가 없게 됨. idle한 thread가 남아있지 않을 경우 job은 대기 큐에 들어가지만 메모리 이슈가 생길 수 있다. OOM 발생!
사이즈 제한이 있는 큐. idle한 thread도 남아있지 않고 큐도 꽉 찬 상태에서 job이 도착할 경우 해당 job은 거부된다.