ThreadLocal의 동작을 외운 수준인지, 아니면 스레드풀 재사용과 비동기 전환이라는 실제 실행 환경 위에서 안전하게 다룰 줄 아는지를 가르려는 질문이다.
ThreadLocal은 각 스레드 내부의 ThreadLocalMap에 키-값을 보관해 스레드끼리 공유 없이 값을 들고 다니게 한다. 락 없이 요청 스코프 정보를 흘릴 수 있어 트랜잭션 동기화, SecurityContext, MDC 같은 인프라가 이 위에 올라가 있다. 단 톰캣·WAS의 스레드풀은 스레드를 재사용하므로, 요청이 끝날 때 remove()로 슬롯을 비우지 않으면 다음 요청에 이전 사용자 값이 그대로 새어 나온다. 즉 '스레드 = 요청 하나'라는 가정 위에서만 안전하게 동작하는 도구다.
두 번째 요청부터 다른 사용자 정보가 보이는 버그를 잡다가 remove() 누락이 원인이었던 경험이 있다면, 스레드풀 재사용 가정이 깨지는 패턴과 묶어 풀어낼 수 있다
@Async로 옮긴 뒤 로그에서 traceId나 사용자 정보가 비기 시작한 경험이 있다면, TaskDecorator로 MDC·SecurityContext를 전파한 이야기로 이을 수 있다
ThreadLocal에 데이터를 캐시처럼 쌓다 힙 덤프에서 누수를 확인했다면, 요청 스코프와 캐시 스코프를 분리한 결정으로 연결할 수 있다
WebFlux로 옮기면서 ThreadLocal 기반 컨텍스트가 깨졌다면, Reactor Context로 갈아탄 과정과 이유를 풀어낼 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.