📖 ✏️
- TIL 시리즈에 작성된 글은 '매일 매일 학습한 지식 조각을 메모해 놓은 포스팅'입니다. 공유가 아닌 개인적인 학습 내용 기록을 목적으로 작성되었음을 알려드립니다.
- 그 외 시리즈에 작성된 공유 목적의 포스팅은 시간이 날 때마다 별도로 작성하고 있습니다. 주로, TIL 시리즈에 작성된 내용에서 특정 주제를 선정하고, 더 깊이 공부한 후 정리하여 작성합니다.
스프링 컨테이너가 싱글톤 방식인 이유
스프링은 현재 웹 애플리케이션을 만들기 위해 주로 사용되고 있다. 웹 애플리케이션의 특성상 동시에 여러 고객이 사용하는 경우가 많다. 동시에 사용한다는 것은 프로그램 내에서 동시에 객체 호출이 발생하는 것을 의미한다.
스프링이 웹 애플리케이션 개발에 강점이 있는 이유는 싱글톤 컨테이너 기능을 제공하기 때문이다. 싱글톤 컨테이너란, 컨테이너의 Bean으로 등록된 객체를 싱글톤 패턴으로 사용한다는 것을 의미한다. 여러명의 고객이 동시에 객체를 요청했을 때, 단 하나의 객체를 공유하는 방식으로 요청을 처리한다.
스프링 없는 순수한 DI 컨테이너는 어떤 문제점이 있을까?
웹 애플리케이션에서 하나의 객체를 공유하는 싱글톤 방식이 왜 필요한지 이해하고 싶다면, 싱글톤 패턴이 아닌 경우를 살펴보자. 어떤 문제점이 있는지 이해할 수 있으면, 싱글톤 패턴의 장점 또한 자연스럽면 이해할 수 있다.
아래 테스트 코드는 순수한 DI 컨테이너 방식으로 만들어졌다. AppConfig 객체를 이용해 서로 다른 2개의 MemberService() 객체를 생성한다. 이때 객체의 참조값을 확인해 보면, 생성된 2개의 MemberService 객체는 서로 다른 객체다.
테스트 코드는 서로 다른 객체임을 증명하기 위해 주소값을 출력하여 비교한다. 결과와 같이 서로 다른 주소값을 가진다. isNotSameAs()을 이용해 서로 다른 객체임을 증명하는 테스트 코드도 패스한다. 두 객체가 엄연히 다른 객체임이 확인 되었다.
public class SingletonTest {
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer() {
AppConfig appConfig = new AppConfig();
// 1. 조회: 호출할 때마다 객체를 생성하는가?
MemberService memberService1 = appConfig.memberService();
// 2. 조회: 호출할 때마다 객체를 생성하는가?
MemberService memberService2 = appConfig.memberService();
// 참조값이 다른 것을 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// memverService1 != memberService2
Assertions.assertThat(memberService1).isNotSameAs(memberService2);
}
}
객체 호출이 발생할 때마다 서로 다른 객체가 생성되는 것은 많은 리소스 낭비를 유발한다. 특히 동시접속이 몇 만 단위로 발생하는 대규모 웹 애플리케이션이라면 메모리 낭비가 더욱 심하다.
하나의 객체를 생성하고 공유하는 싱글톤은 이와 같은 문제를 해결한다. 매번 객체를 생성하지 않기 때문에 메모리의 효율적 사용이 가능하다. 스프링은 싱글톤 방식의 컨테이너를 지원한다. 싱글톤 기능은 여러 고객이 동시에 이용해야하는 웹 애플리케이션 개발에 스프링을 사용하는 이유 중 하나이다.
요약
- 요청마다 객체가 새로 생성되는 방식은 필연적으로 비효율을 발생시킨다. 고객의 요청이 많은 애플리케이션은 메모리 낭비가 발생한다.
- 이에 대한 해결책으로 싱글톤 패턴이 등장한다. 싱글톤 패턴은 객체를 딱 1개만 생성(싱글)하고, 요청이 발생하면 객체를 공유하는 설계 방법론이다.
