정책 이름을 외워서 나열하는지, 아니면 거부 순간 호출 경로·큐·업스트림 풀에 어떤 영향이 전파되는지를 같이 보고 고르는지를 가른다. CallerRunsPolicy의 연쇄 포화 같은 코너 케이스를 짚으면 깊이가 드러난다.
ThreadPoolExecutor는 core와 max 스레드, workQueue가 모두 찼을 때 신규 작업을 RejectedExecutionHandler로 넘긴다. 기본 제공 정책은 네 개다. AbortPolicy는 예외를 던져 호출자에게 책임을 넘기고, CallerRunsPolicy는 호출 스레드가 직접 작업을 실행해 자연스러운 백프레셔를 만든다. DiscardPolicy는 조용히 버리고, DiscardOldestPolicy는 큐 맨 앞 작업을 버린 뒤 새 작업을 받는다. 어떤 정책도 "안전한 기본값"이 아니라, 처리 보장이 중요한지·지연을 호출 경로에 전가해도 되는지·유실을 감수할 수 있는지를 보고 고른다.
트래픽 폭주로 호출 스레드까지 같이 마른 장애를 겪었다면, CallerRunsPolicy의 연쇄 포화가 어떻게 퍼지는지 사례로 연결할 수 있다
거부된 작업을 외부 큐(Kafka·SQS 등)로 다시 밀어 넣어 유실을 막은 경험이 있다면, 커스텀 핸들러 설계 근거로 풀어낼 수 있다
거부율·큐 길이·활성 스레드 수를 대시보드로 잡아봤다면, 정책 선택과 관측성을 한 묶음으로 설명할 수 있다
큐 크기를 무한대로 두다 OOM을 본 경험이 있다면, 큐 상한 설정이 정책 선택보다 앞서야 하는 이유로 쓸 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.