스레드 풀 : 스레드 풀을 이용하는 이유?

스레드 풀을 쓰는 이유를 한 문장으로: 스레드를 매번 만들고 없애며 개수를 사람이 조정하는 대신, core / max / queue / keepAlive / 거절 정책을 한 번 계약으로 정해 두면 풀이 부하에 따라 스레드를 자동으로 늘리고 줄이기 때문.

0. 스코핑 경계 (Scoping Boundary)

이 노트는 플랫폼 스레드를 관리하는 풀(ThreadPoolExecutor) 을 다룹니다.

1. "풀(Pool)"이란 무엇인가 — 단어부터 정의

• 사전적 의미: 재사용 가능한 자원을 미리 확보해 둔 저수지(reservoir).
• 스레드 풀의 구성 = 세 부분:

스레드 풀 = [재사용 스레드 집합]  +  [대기 작업 큐]  +  [스케일링·거절 정책]
             └ 빌려 쓰고 반납        └ 처리 못한 작업     └ 언제 늘리고 줄이고 거절할지

• 커넥션 풀(HikariCP), 객체 풀과 같은 계열입니다: 비싼 자원을 "생성/소멸의 대상"이 아니라 "빌리고 돌려주는 대상"으로 취급.
• 따라서 스레드 풀을 이해한다는 것은 곧 위 세 부분의 파라미터를 이해하는 것입니다(3장).

2. 수동 관리의 한계 — 왜 매번 손대면 안 되는가

2.1 new Thread() 반복의 비용

• 생성·소멸: OS 시스템 콜, 스레드 스택 메모리 할당(Xss 기본 512KB~1MB).
• 컨텍스트 스위칭: 스레드가 많아질수록 스케줄러 오버헤드가 처리량을 잠식.
• 무제한 생성: OutOfMemoryError: unable to create new native thread 또는 시스템 전체 불안정.

2.2 사람이 개수를 계속 조정할 수 없다

• 트래픽은 초 단위로 변합니다. "지금 몇 개가 적정인가"를 매번 판단·반영하는 것은 불가능.
• 해결의 방향: 개수를 직접 정하지 않고 규칙(정책)을 위임한다 → 풀.

3. 풀에서 미리 "정해야 하는 값" (정책 = 계약)

ThreadPoolExecutor의 생성자 파라미터가 곧 계약서입니다.

이 값들을 한 번 정하면, 이후 스레드 증감은 풀이 알아서 합니다.

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    10,                       // corePoolSize
    50,                       // maximumPoolSize
    60L, TimeUnit.SECONDS,    // keepAliveTime: 유휴 60초 후 초과분 반납
    new ArrayBlockingQueue<>(1_000),   // 유한 큐
    namedFactory("worker-"),
    new ThreadPoolExecutor.CallerRunsPolicy()  // 포화 시 제출 스레드가 직접 실행
);

4. 자동 스케일링 메커니즘 (이 노트의 핵심)

4.1 확장 순서 — core → queue → max

1. 스레드 수 < corePoolSize → 새 코어 스레드 생성해 즉시 실행.
2. 코어가 다 참 → 큐에 적재(대기).
3. 큐도 다 참 & 스레드 수 < maximumPoolSize → 임시 스레드 생성해 실행.
4. 큐도 차고 스레드도 max → 거절 정책 실행.

4.2 축소 — keepAlive

• 부하가 줄면, maximumPoolSize까지 늘었던 초과 스레드가 keepAliveTime 동안 놀면 회수됩니다(코어까지 축소).
• allowCoreThreadTimeOut(true) 를 켜면 코어 스레드도 유휴 시 반납되어 0까지 축소 가능.

4.3 큐 선택이 스케일링 "성격"을 결정한다 ⚠

• Executors.newFixedThreadPool() = 무제한 LinkedBlockingQueue → 큐가 힙을 잠식하다 지연된 OOM.
• Executors.newCachedThreadPool() = SynchronousQueue + Integer.MAX_VALUE max → 스레드 폭증 위험.

4.4 거절 정책과 백프레셔

5. "직접 만들지 말라" — 안전한 생성 경로

• Executors.* 팩토리 메서드는 숨은 무제한(큐 또는 스레드)이 있으므로 운영 코드에서 지양.
• ThreadPoolExecutor를 직접 구성하거나, Spring의 ThreadPoolTaskExecutor에 값을 명시.
• 관측 지표: getActiveCount(), getQueue().size(), getCompletedTaskCount(), 거절 카운트 → 대시보드/알람 연결.

6. 풀 크기의 출발점 (정답이 아니라 시작점)

• CPU 바운드: 대략 코어 수(또는 코어 수 + 1).
• I/O 바운드: 대략 코어 수 × (1 + 대기시간/서비스시간).
• 리틀의 법칙 관점에서 추정하되, 부하 테스트로 붕괴 지점을 찾아 그보다 낮게 설정합니다. 고정 수치는 권고하지 않습니다.
• 다운스트림 정합: 워커 풀 크기가 DB 커넥션 풀(maximumPoolSize)보다 크면, 초과 워커는 커넥션 대기로 묶입니다. 두 상한을 함께 봅니다. → Java - 대용량 트래픽·비동기 병렬 환경의 메모리·리소스 한계 관리

7. 풀을 "덜 신경 써도 되는" 방향

• 가상 스레드(Java 21, newVirtualThreadPerTaskExecutor()): 스레드가 매우 가벼워 "스레드 수 상한"이라는 관리 항목 자체가 사라집니다.

• 그러나 다운스트림 동시성 제한(Semaphore 등)은 여전히 필요 — 백만 개의 가상 스레드가 커넥션 풀에 몰리면 그대로 병목입니다. → Java Virtual Threads - Pinning 현상과 해결 방안

• ForkJoinPool.commonPool(): parallelStream이 공유하므로, 여기서 블로킹 작업을 하면 전역 영향. CPU 바운드 계산에 한정.

• Bulkhead: 기능별로 풀을 분리해, 한 기능의 폭주가 전체를 죽이지 않도록 격벽.

8. 안티패턴 체크리스트

• 무제한 큐(new LinkedBlockingQueue<>()), newFixedThreadPool/newCachedThreadPool 무비판 사용
• maximumPoolSize만 키우고 큐는 무제한 → max가 동작하지 않음
• 요청마다 새 Executor 생성(풀의 의미 상실) 후 shutdown() 누락
• 풀 안의 작업이 같은 풀의 다른 작업 결과를 대기(스레드 고갈 데드락)
• 풀링된 스레드에서 ThreadLocal 사용 후 remove() 누락 → 누수
• CPU 코어 수와 무관하게 관행적 수치(200 등) 복붙