1. 싱글톤 컨테이너
1) 싱글톤 패턴
스프링은 태생이 기업용 온라인 서비스 기술을 위해 탄생했다. 대부분의 스프링 애플리케이션은 웹이고 보통 여러 고객이 동시에 요청을 한다. 스프링 없는 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성하여 메모리 낭비가 심하다. 그럼 어떻게 할까 ❓
클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴인 "싱글톤 패턴"을 적용한다.
🖥️ SingletonService
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("싱글톤 객체 로직 호출");
}
}즉 객체 인스턴스가 2개 이상 생성되지 못하도록 private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 막는다.
싱글톤 패턴을 구현하는 방법은 여러가지며 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 사용함
⚠️ 문제점
- 싱글톤 패턴 구현하는 코드 자체가 많이 들어감
- 의존관계상 클라이언트가 구체 클래스에 의존 -> DIP, OCP 위반
- 테스트나 내부 속성 변경 또는 초기화가 어려움
- private 생성자로 자식 클래스를 만들기 어려움
✅ 결론적으로 유연성이 떨어지며 안티패턴으로 불리기도 함
2) 싱글톤 컨테이너
싱글톤 패턴 문제를 해결하며, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 학습한 스프링 빈이 싱글톤으로 관리되는 빈이다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 함
- 스프링 컨테이너는 싱글톤 패턴 사용하지 않아도 객체 인스턴스를 싱글톤으로 관리함
- 싱글톤 객체 생성, 관리하는 기능을 싱글톤 레지스트리 라고 함
⚠️ 싱글톤 방식의 주의점
- 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됨
- 무상태(stateless)로 설계해야함
- 특정 클라이언트에 의존적이거나 값을 변경할 수 있는 필드가 있으면 안됨
- 가급적 읽기만 가능해야함
- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 사용해야함
3) @Configuration과 싱글톤
그런데 이상한 점이 있다. AppConfig를 보자
@Bean
public MemberService memberService(){
System.out.println("call AppConfig.memberService");
return new MemberServiceImpl(memberRepository());
}
@Bean
public OrderService orderService(){
System.out.println("call AppConfig.orderService");
return new OrderServiceImpl(memberRepository(),
discountPolicy());
}
@Bean
public MemberRepository memberRepository(){
System.out.println("call AppConfig.memberRepository");
return new MemoryMemberRepository();
}memberService 빈을 만드는 코드를 보면 memberRepository()를 호출하고 이 메서드를 호출하면 new MemoryMemberRepository()를 호출한다. orderService빈을 만드는 코드도 동일하다. 그럼 각 다른 2개의 MemoryMemberRepository가 생성되면서 싱글톤이 깨지는거 처럼 보인다.
즉, Bean등록과 위 두가지 로직을 통해 memberRepository()는 3번 호출되어야한다. (깨진 상태라 생각) 호출 로그를 넣어 확인해보자
결과는! 모두 한번만 호출된다. 어떻게 가능할까❓
스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장하기 위해 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
@Test
void configurationDeep() {
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean.getClass());
}- AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록됨 -> AppConfig도 스프링 빈이 됨
- 순수 클래스라면 class hello.core.AppConfig가 출력 되어야하지만 출력 결과는 아래와 같이 나옴
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70 - 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB이라는 기술로 AppConfig를 복제해서 특별히 수정된 새로운 클래스를 만들고 그걸 스프링 빈으로 등록한 것이다.
- 바로 그 새로운 클래스가 싱글톤이 보장되도록 해줌. 아마도 아래와 같이 작성되었을 것임
@Bean
public MemberRepository memberRepository() {
if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
return 스프링 컨테이너에서 찾아서 반환;
}
else { //스프링 컨테이너에 없으면 기존 로직을 호출해서
//MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
return 반환
}
}❓ 만약 @Configuration을 적용하지 않고 @Bean만 적용한다면 ❓
@Configuration을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해 싱글톤을 보장하지만, 없다면 스프링 빈으로 등록은 되지만 싱글톤이 보장되진 않는다.
