싱글톤 컨테이너

Yerim·2021년 8월 24일

Spring

목록 보기

5/9

✔ Inflearn 강의 수강 내용 정리글입니다!

웹 애플리케이션과 싱글톤

대부분의 스프링 애플리케이션은 웹 애플리케이션
웹 애플리케이션은 대부분 여러 고객이 동시에 요청

💡 스프링 없는 순수한 DI 컨테이너

 AppConfig appConfig = new AppConfig();
 
 //1. 조회: 호출할 때 마다 객체를 생성
 MemberService memberService1 = appConfig.memberService();
 
 //2. 조회: 호출할 때 마다 객체를 생성
 MemberService memberService2 = appConfig.memberService();
 
 //참조값이 다른 것을 확인
 System.out.println("memberService1 = " + memberService1); System.out.println("memberService2 = " + memberService2); //memberService1 != memberService2
 assertThat(memberService1).isNotSameAs(memberService2);

AppConfig는 요청할 때마다 새로운 객체 생성 ➡ 메모리 낭비가 심하다!
➡ 싱글톤 패턴

싱글톤 패턴

클래스의 인스턴스가 한 개만 생성되는 것을 보장하는 디자인 패턴
객체 인스턴스를 두 개 이상 생성하지 못하도록 막아야한다.
➡ private 생성자를 이용하여 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야한다.

public class SingletonService {

 //1. static 영역에 객체를 딱 1개만 생성해둔다.
 private static final SingletonService instance = new SingletonService();
 
 //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록
허용한다.
 public static SingletonService getInstance() {
 	return instance;
 }
 
 //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
 private SingletonService() {
 }
 
 public void logic() {
 	System.out.println("싱글톤 객체 로직 호출");
 }
}

해당 객체 instance는 오직 getInstance() 메서드를 통해서만 조회 가능
private 생성자를 통하여 외부에서 new 키워드로 새로운 객체 인스턴스가 생성되는 것을 막는다.
싱글톤 패턴을 사용한 코드

public void singletonServiceTest() {

 //private으로 생성자를 막아두었다. 컴파일 오류가 발생한다.
 //new SingletonService();
 
 //1. 조회: 호출할 때 마다 같은 객체를 반환
 SingletonService singletonService1 = SingletonService.getInstance();
 
 //2. 조회: 호출할 때 마다 같은 객체를 반환
 SingletonService singletonService2 = SingletonService.getInstance();
 
 //참조값이 같은 것을 확인
 System.out.println("singletonService1 = " + singletonService1);
 System.out.println("singletonService2 = " + singletonService2);
 
 // singletonService1 == singletonService2
 assertThat(singletonService1).isSameAs(singletonService2); singletonService1.logic();
}

💡 싱글톤 패턴의 문제점

싱글톤 패턴 구현 코드 자체가 많다.
의존관계상 클라이언트가 구체 클래스에 의존 ➡ DIP 위반
➡ OCP 위반 가능성 ⬆
내부 속성 변경이나 초기화가 어렵다.
private 생성자로 자식 클래스를 만들기 어렵다.

➡ 유연성이 떨어진다!(안티패턴으로 불리기도함)

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 1개만 생성하여 관리(싱글톤)

💡 싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체를 싱글톤으로 관리
스프링 컨테이너는 싱글톤 컨테이너 역할 ➡ 싱글톤 레지스트리
싱글톤 패턴을 위한 코드가 필요없음 ➡ DIP, OCP, private 생성자로부터 자유로움

void springContainer() {

 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
 
 //1. 조회: 호출할 때 마다 같은 객체를 반환
 MemberService memberService1 = ac.getBean("memberService", MemberService.class);

 //2. 조회: 호출할 때 마다 같은 객체를 반환
 MemberService memberService2 = ac.getBean("memberService", MemberService.class);
 
 //참조값이 같은 것을 확인
 System.out.println("memberService1 = " + memberService1);
 System.out.println("memberService2 = " + memberService2);
 
 //memberService1 == memberService2
 assertThat(memberService1).isSameAs(memberService2);
}

📍 싱글톤 컨테이너 적용 후

고객 요청이 올 때마다 새로운 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유

💡 싱글톤 방식의 주의점

여러 클라이언트가 하나의 객체를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 ❌
무상태(stateless)로 설계
- 특정 클라이언트에 의존적인 필드 존재 ❌
- 특정 클라이언트가 값을 변경할 수 있는 필드 존재 ❌
- 가급적 읽기만 가능 ➡ 수정이 불가해야 함
- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal등을 사용

 public void order(String name, int price) {
 	System.out.println("name = " + name + " price = " + price);
 	this.price = price; //여기가 문제!
 }

@Configuration과 싱글톤

@Configuration
public class AppConfig {

 @Bean
 public MemberService memberService() {
 	return new MemberServiceImpl(memberRepository());
 }
 
 @Bean
 public OrderService orderService() {
 	return new OrderServiceImpl(memberRepository(), discountPolicy());
 }
 
 @Bean
 public MemberRepository memberRepository() {
 	return new MemoryMemberRepository();
 }
}

memberService 에서 memberRepository() 호출
orderService 에서 memberRepository() 호출
➡ 다른 2개의 MemoryMemberRepository 생성 ❓

➡ 결과적으로 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용

@Configuration과 바이트 코드 조작의 마법

스프링은 클래스의 바이트코드를 조작하는 라이브러리 사용

void configurationDeep() {

 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
 
 //AppConfig도 스프링 빈으로 등록된다.
 AppConfig bean = ac.getBean(AppConfig.class);
 
 System.out.println("bean = " + bean.getClass());
 //출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
}

AppConfig 도 스프링 빈으로 등록된다.
AppConfig 스프링 빈을 조회하여 클래스 정보 출력
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용하여 AppConfig 클래스를 상속받은 임의의 다른 클래스 생성 ➡ 그 클래스를 스프링 빈으로 등록
임의의 다른 클래스가 싱글톤이 되도록 보장

📍
@Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록 후 반환
➡ 싱글톤 보장!