싱글톤 레지스트리
@Configuration
public class AppConfig {
@Bean
public MemberService memberService(){
System.out.println("AppConfig.memberService");
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemoryMemberRepository memberRepository() {
System.out.println("AppConfig.memberRepository");
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService() {
System.out.println("AppConfig.orderService");
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
@Bean
public DiscountPolicy discountPolicy() {
System.out.println("AppConfig.discountPolicy");
return new RateDiscountPolicy();
}
}AppConfig appConfig = new AppConfig();스프링 없는 순수 DI 컨테이너
Appconfig를 호출하면 요청을 할때마다 새로운 객체가 만들어진다. 근데 문제점은 고객 요청이 올때마다 계속 객체가 새롭게 만들어진다.
- ex) orderservice가 100번 호출되면 memberRepository와 discountPolicy가 계속 new 로 다시 만들어진다 100번호출 -> 200개 객체생성 즉, 메모리낭비가 매우 심해진다.
근데 어쩔수가 없다 순수한 자바코드이기 때문에 그러면 이 문제를 해결하기위해
디자인 패턴중에 싱글톤 패턴을 사용하게 된다.
싱글톤 패턴
싱글톤 패턴은 간단히 말하면 객체를 static 영역에 하나만 생성해놓고 그 하나를 전체가 공유하게 된다.
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("싱글톤 객체 로직 호출");
} }근데 보시다시피 싱글톤패턴을 구현하게되면 이렇게
- 구현하는 코드가 많이 들어가게 된다.
- private 생성자를 쓰기 때문에 자식클래스를 못만든다 그럼 객체지향의 핵심인 상속과 다형성을 활용하기 어렵다.
- 테스트하기 어렵다 -> 만드는게 제한적이라서 테스트할때 mock오브젝트 등으로 대체하기가 힘들다
스프링 싱글톤 컨테이너
ApplicationContext ac = new
AnnotationConfigApplicationContext(AppConfig.class);appconfig의 설정정보로 스프링 컨테이너를 만들어주었다. 그리고
@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
// AppConfig appConfig = new AppConfig();
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
//1. 조회: 호출할때 마다 객체를 생성
MemberService memberService1 = ac.getBean("memberService",MemberService.class);
MemberService memberService2 = ac.getBean("memberService",MemberService.class);
//참조값이 같은것을 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
//memberService != memberService2
Assertions.assertThat(memberService1).isSameAs(memberService2);
/**
memberService1 = hello.core.member.MemberServiceImpl@27f9e982
memberService2 = hello.core.member.MemberServiceImpl@27f9e982
**/
}
}테스트를 해보면 같은 참조값을 사용하고 있다 , 즉 스프링이 싱글톤을 구현해준것이다 하지만 주의해서 사용해야된다.
이 객체를 하나만 생성해서 공유하기때문에 stateful하게 설계하면 안된다.
-> Stateless하게 설계해야한다.
- 가급적 읽기만 가능해야하고
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 필드 대신에 자바에서 공유되지않는 값, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
스프링이 어떻게 싱글톤을 구현한것일까?
왜냐하면 각 객체를 bean으로 만들었기 때문이다.
- bean이란 이제 스프링에게 관리를 맡기고 스프링이 직접 생성과 제어를 담당하게 되는 object를 bean이라고 한다.
스프링은 설정정보가 있는 클래스(@Configration)를 빈으로 만들때 직접등록하는게아니라 CGLIB이라는 라이브러리를 사용해서 Appconfig를 상속받는 임의의 클래스를 bean으로 등록한다 그 과정에서 설정정보에 있는 bean이 스프링 컨테이너에 이미 있으면 그걸 반환하고 아니면 새로 스프링 컨테이너에 등록하는 방식으로 동작한다.
