인프런 강의 < 스프링 핵심 원리 - 기본편 > 정리
웹 어플리케이션과 싱글톤
- 웹 어플리케이션은 여러 고객이 동시에 요청을 한다.
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);
//memberService1 != memberService2
assertThat(memberService1).isNotSameAs(memberService2);
}
}- 위의 순수한 DI 컨테이너 테스트는 AppConfig 요청을 할때마다 객체를 생성한다.
- 메모리 낭비 발생
객체 1개만 생성하고, 그걸 공유하도록 한다. = 싱글톤 패턴
싱글톤 패턴
- 클래스의 인스턴스가 단 1개만 생성되는 것을 보장하는 디자인 패턴
- private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하게 해야함
public class SingletonService {
private static final SingletonService instance = new SingletonService();
public static SingletonService getInstance() {
return instance;
}
private SingletonService(){
}
public void logic() {
System.out.println("싱글톤 객체 로직 호출");
}
}- static 영역에 객체 instance를 하나 생성한다.
getinstance()메서드를 통해서 조회 할 수 있다.- private로 생성하여 외부에서 사용 불가
싱글톤 패턴 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 테스트하기 어렵다.
- 내부 속성을 변경하거나 초기화 하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어렵다.
- 결론적으로 유연성이 떨어진다.
- 안티패턴으로 불리기도 한다.
싱글톤 컨테이너
- 스프링 컨테이너는 위의 싱글톤 패턴의 문제점을 모두 해결 가능하다.
- 스프링 빈은 싱글톤으로 관리된다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 하고 이렇게 싱글톤 객체를 생성하고 관리하는 기능을
싱글톤 레지스트리라고 한다.
싱글톤 컨테이너 적용 후
싱글톤 방식의 주의점
-
stateful x -> stateless
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal등을 사용해야 한다.
-
stateful 예시
public class StatefulService {
private int price; //상태를 유지하는 필드
public void order(String name, int price) {
System.out.println("name = " + name + " price = " + price);
this.price = price; //여기가 문제!
}
public int getPrice() {
return price;
}
}
public class StatefulServiceTest {
@Test
void statefulServiceSingleton() {
ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);
//ThreadA: A사용자 10000원 주문
statefulService1.order("userA", 10000);
//ThreadB: B사용자 20000원 주문
statefulService2.order("userB", 20000);
//ThreadA: 사용자A 주문 금액 조회
int price = statefulService1.getPrice();
//ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
System.out.println("price = " + price);
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
static class TestConfig {
@Bean
public StatefulService statefulService() {
return new StatefulService();
}
}
}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();
}
@Bean
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
}memberService빈을 만들면memberRepository()를 호출한다.memberRepository는new MemoryMemberRepository()를 호출한다.
orderService빈을 만들면memberRepository()를 호출한다.memberRepository는new MemoryMemberRepository()를 호출한다.
문제
각각 다른 두개의 MemoryMemberRepository가 생성되어 싱글톤이 깨지는 것처럼 보인다.
테스트
@Configuration
public class 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();
}
@Bean
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
}call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService- 예상과 다르게 싱글톤이 깨지지 않고 한번씩만 출력된다.
@Configuration과 바이트코드 조작
- 테스트
@Test
void configurationDeep() {
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean.getClass());
}- 결과
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70- 순수한 클래스에서 나와야 하는 결괴
class hello.core.AppConfig이유
- 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스(
AppConfig@CGLIB)를 스프링 빈으로 등록
@Bean
public MemberRepository memberRepository() {
if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면 ?){
return 스프링 컨테이너에서 찾아서 반환;
} else{ //스프링 컨테이너에 없으면
기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
return 반환
}
}- @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다
- 해당 클래스가 싱글톤을 보장해준다.
결론
@Configuration이 없다면 @Bean만으로는 빈 등록은 가능하지만 싱글톤을 보장해줄 수 없다.
< 자료 출처: 스프링 핵심 원리 - 기본편 >
💻Backend Developer