쓰레드라는 키워드는 정말 무수히 뻗어나가는 가지를 지닌 나무 같습니다. 무수히 많은 가지만큼, 아래로 뻗어있는 뿌리도 아주 깊고 넓습니다. 서버 성능 측정 및 튜닝 관련하여 쓰레드풀, 커넥션풀 등의 키워드가 떠오르고 CPU의 쓰레드, OS의 쓰레드까지 하나의 단어가 여러 맥락에서 사용되기도 하고.. 결국 한 스푼 한 스푼 떠먹는 수밖에 없는 것 같습니다! 조금씩 조금씩 쌓아가보죠~! 쓰레드 풀(Thread Pool)이란? 쓰레드 풀은 제한된 수 만큼의 쓰레드를 미리 생성해두는 곳을 말합니다. 이를 통해 아래와 같은 장점을 취할 수 있습니다. 향후 새로운 처리를 위해 스레드 생성 비용을 매번 발생시키지 않게 된다 스레드의 과도한 증폭으로 인한 CPU, 메모리 사용에 따른 성능 저하를 방지한다 요청이 많아져..
나만의 라이브러리를 만들어서 배포해봅시다! Bearer 토큰 추출을 조금 더 쉽게 할 수 없을까 로그인, 인증/인가 과정은 어느 프로젝트를 하더라도 추가하게 되기 마련인데요, 이 과정에서 Authorization Header에 담긴 Bearer 토큰을 추출해내는 코드를 매번 프로젝트에 복사 붙여넣기로 추가하는 과정이 너무 번거롭게 느껴졌습니다. 저만 느끼는 감정이 아닐 것이기에 분명 이미 만들어진 무언가가 있으리라 생각했는데, Spring Security OAuth쪽 패키지에 DefaultBearerTokenResolver가 있는 것을 확인했습니다. 그러나 이 클래스는 특정 의존성 이 제공하는 클래스 중 하나의 구성요소여서 다른 의존성도 함께 추가할 수밖에 없다는 점과, 일부 내부 구현이 저의 사용 의도..
팀 프로젝트 중 DTO 사용 관련 논의가 있었습니다. DTO 내에 getter이외의 로직을 담지 않는 게 어떨지 제안하는 과정에서 제가 생각하는 DTO에 대한 정의를 이야기해보았습니다. 이와 관련해 다시 한 번 정리해봅니다. DTO 내 기본적 유효성 검증을 묶어주는 메서드를 만들어도 괜찮을까? public class SlackMessageRequest { @Nullable private String keyword; @Nullable @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) private LocalDateTime date; @NotNull private List channelIds; private boolean needPastMessage = true; ..
new A(new B(new C())) 위와 같이 A, B, C가 의존관계에 있고 셋 모두 스프링 빈에 등록되어야 할 대상일 때, 스프링 컨테이너에서는 어떻게 인스턴스를 만들까요? 실제 구현 내용을 모른다면, 직접 구현한다면 어떻게 구현하실지 말씀해주시겠어요? 위 질문은 얼마 전 진행됐던 레벨 인터뷰에서 브라운이 인터뷰이에게 했던 질문입니다. 옵저버로서 해당 인터뷰를 관찰하면서도, 뜻밖에 질문에 저 또한 속으로 대답을 떠올려보고 있었습니다. 제 속에 떠올랐던 대답은 "현재 생성할 수 있는 인스턴스를 생성하는 사이클을 반복한다" 였습니다. 아래처럼요. 1) A는 B가 아직 생성 안되었기에 넘어가고, B도 마찬가지입니다. 그러면 C를 생성하고 mark 합니다. 2) A는 여전히 B가 없으니 넘어가고, B는 ..
이전 포스팅에서는 HTTP 메시지와 Servlet의 등장, 그리고 Front Controller 패턴까지 알아봤습니다. 이번 포스팅에서는 스프링의 Front Controller인 DispatcherServlet에 handler들이 어떻게 등록되는지 살펴보겠습니다. 요약 최초의 스프링은 핸들러 인터페이스를 구현한 클래스를 스프링 빈으로 등록하여 핸들러로 등록했습니다. @Component("/urlPattern") 식으로 스프링 빈을 등록하는 것이죠. 이들을 BeanNameUrlHandlerMapping 이 탐지해서 등록해뒀다가 탐색 시 사용됐습니다. 요즘에는 RequestMapping 애너테이션 기반 핸들러 등록 방법이 많이 사용됩니다. RequestMappingHandlerMapping은 @Control..
