producer submits work
-> bounded or unbounded queue
-> reusable workers pull tasks
-> task completes or reports failure
-> worker returns to pool

작업 크기

아주 작은 작업을 지나치게 잘게 나누면 enqueue, wakeup, context switch 비용이 실제 계산보다 커질 수 있습니다. 반대로 한 작업이 너무 오래 blocking하면 worker가 점유되어 뒤 작업이 진행하지 못하는 starvation이 생길 수 있습니다.

CPU-bound pool은 core 수와 작업 특성을 기준으로 제한하고, blocking I/O는 async API 또는 별도 제한된 pool을 검토합니다. 하나의 global pool에 장시간 blocking 작업과 짧은 latency 작업을 섞으면 서로 영향을 줍니다.

종료와 실패

Shutdown에서는 새 작업 접수를 멈추고, queue를 drain할지 취소할지, 실행 중인 작업을 얼마나 기다릴지 결정합니다. 작업 예외가 worker thread를 조용히 종료시키거나 누락되지 않도록 결과를 수집하고 기록합니다.

자주 틀리는 점

• 요청마다 새 thread를 만드는 구조를 thread pool이라고 부르지 않습니다.
• Queue 길이를 제한하지 않으면 memory와 latency가 함께 증가할 수 있습니다.
• Pool 크기를 CPU core 수 하나로만 고정하지 않습니다. Blocking 비율을 함께 봅니다.
• Thread-local 상태가 worker 재사용 뒤 다음 작업에 남지 않도록 정리합니다.