스프링 핵심 원리 기본 - 싱글톤 컨테이너

스프링으로 개발하지 않고 순수 자바로 개발한다고 합시다. 고객 요청이 들어올 때마다 새로운 객체를 생성하고 객체가 쌓이고 쌓이다 보면 트래픽이 감당이 안 되는 상황이 올 것이다. 그렇다면 어떻게 해결해야 할까? 이미 존재하고 있는 객체를 조회해서 사용하면 객체를 계속해서 만들 필요도 없고 트래픽 문제도 해결이 될 것입니다.

싱글톤 적용 전

싱글톤 패턴

싱글톤 패턴은 클래스의 객체를 딱 1개만 생성하고 공유할 수 있게 해주는 디자인 패턴입니다.

 

싱글톤 패턴 구현

public class SingletonService {

  private static final SingletonService instance = new SingletonService();

  public static SingletonService getInstance() {
    return instance;
  }

  private SingletonService() {
  }

  public void logic() {
    System.out.printf("싱글톤 객체 로직 호출출");
  }
}

1. static 영역에 객체를 하나만 생성한다.
2. 이 객체 인스터스는 오직 getInstance() 메서드를 통해서만 조회할 수 있다.
3. 생성자를 private로 막음으로써 외부에서 new 키워드로 객체가 생성되는 것을 막는다.  

 

싱글톤 패턴 테스트 코드

@Test
 @DisplayName("싱글톤 패턴을 적용한 객체 사용")
 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 생성자로 자식 클래스를 만들기 어렵다.
• 내부 속성을 변경하거나 초기화하기 어렵다.

 

싱글톤 컨테이너(스프링 컨테이너)

싱글톤 컨테이너 적용 그림

 

 

• 싱글톤 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 한 개만 생성하여 관리한다.
• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

 

스프링 컨테이너 사용

    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void springContainer() {

        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

        System.out.println("memberService1" + memberService1);
        System.out.println("memberService2" + memberService2);

        Assertions.assertThat(memberService1).isSameAs(memberService2);
    }

결과 

memberService1 = com.example.springdemostudy.member.MemberServiceImpl@29523c12
memberService2 = com.example.springdemostudy.member.MemberServiceImpl@42b02524

동일한 객체지만 서로 다른 메모리에 할당되는 것을 알 수가 있습니다.

 

싱글톤 방식의 주의점

• 싱글톤 패턴이나 스프링 컨테이너는 객체 인스턴스를 하나만 생성해서 여러 클라이언트가 공유하기 때문에 상태(stateful)를 유지하게 설계하면 안 된다. 
• 무상태(stateless)로 설계해야 한다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
  • 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

public class StatefulService {

    private int price;

    public int order(String name, int price) {
        this.price = price; // 문제 발생
//      return price;
    }

    public int getPrice() {
        return price;
    }
}

public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

       statefulService1.order("userA", 10000);
       statefulService2.order("userB", 20000);

        int price = statefulService1.getPrice();
        System.out.println(price);
    }

    static class TestConfig {

        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }
}

• StatefulService의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.
• 분명 사용자 A의 주문 금액인 10000원이 출력되어야 하는데, 20000원이 출력될 것이다.
• StatefulService에서 price를 return 받아 필드가 공유되는 것을 막아주자!
• 스프링 빈은 항상 무상태로 설계하자.

 

@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()를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository()를 호출한다.
• orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

결과적으로 가각 다른 2개의 MemoryMemberReposiroty()를 호출하게 되는데 스프링 컨테이너는 이 문제를 어떻게 해결할까?

 

 @Test
    void configurationTest() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberService" + memberRepository1);
        System.out.println("orderService" + memberRepository2);

        Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);

    }

• 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용한다.

 

정리

• Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.
• 스프링 설정 정보는 항상 @Configuration을 사용하자.