ThreadLocal로 관리한 TraceId는 왜 반드시 정리해야 할까요?
본질문
ThreadLocal로 TraceId를 관리할 때, thread pool 재사용 환경에서는 어떤 cleanup이 필요할까요?
왜 이 질문이 나올까요?
요청별 로그를 묶기 위해 TraceId를 ThreadLocal이나 MDC에 넣는 경우가 있습니다. 그런데 thread pool의 작업 스레드는 요청이 끝나도 사라지지 않고 다음 작업에 다시 사용됩니다.
이전 요청이 남긴 TraceId를 정리하지 않으면 다음 요청의 로그에 잘못된 식별자가 붙을 수 있습니다. 반대로 비동기 작업에서는 새 스레드로 컨텍스트가 자동 전달된다고 가정해서도 안 됩니다.
면접 준비 포인트를 이어서 확인하세요
- 면접관이 확인하려는 것잠금
- 같이 체크해볼 포인트5개
- 꼬리질문5개
쿠팡 링크를 클릭하면 오늘은 모든 지난 질문의 면접 의도·체크 포인트·꼬리질문을 볼 수 있어요. 구매는 필요하지 않습니다.
쿠팡 방문 링크를 준비 중이에요. 연결 후 이용할 수 있습니다.
이 사이트는 쿠팡파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받을 수 있습니다.
해제 기록은 같은 브라우저에서 오늘만 유지돼요. 카톡 내부 브라우저·크롬·PC의 기록은 각각 별개입니다.
답변 준비 방향
면접에서는 먼저 스레드 풀의 스레드가 재사용된다는 점을 설명하고, TraceId를 설정한 경계에서 finally로 정리한다고 답하세요. 그다음 비동기 경계의 전달과 정리는 별도로 설계해야 한다고 덧붙이면 좋습니다.
직접 만든 ThreadLocal인지 로깅 MDC인지에 따라 remove/clear의 범위를 구분하고, 중첩된 컨텍스트가 있는 코드라면 이전 값을 복원해야 하는지도 확인하세요.