싱글톤 컨테이너

김영한 강사님의 스프링 핵심 원리 - 기본편 수강 후 정리한 포스팅입니다.

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

 

1. 웹 어플리케이션과 싱글톤

문제점: 고객 요청이 올 때마다 개별 객체를 만들어낸다. 1000번의 요청이 오면, 1000개의 새로운 객체를 생성하는데 이는 메모리 낭비를 초래한다.

해결책: 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. => 싱글톤 패턴

 

싱글톤 패턴

JVM 내에서, 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴. 

 

 

public class SingletonService {
 
    // 생성자를 private 으로 제한했기에, 외부 클래스에서 new 를 사용하여 생성자를 만들 수 없다.
    private SingletonService() {
    }
 
    private static final SingletonService instance = new SingletonService(); 
 
    // instance 변수에 접근할 수 있는 방법은, getInstance() 메서드를 사용하는 방법이 유일하다. 생성자 만들지 못하기에.
    public static SingletonService getInstance() {
        return instance;
    }
 
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

 

 

private 으로 생성자를 제한했기에, 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다. => 이걸 컴파일 단계에서 잡아 줄 수 있다. ( 컴파일 단계에서 에러를 잡을 수 있다는 것은, 잘 짜여진 객체지향 시스템이란 뜻 )

 

 

// SingletonTest.java

public class SingletonTest {
    @Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용") public void singletonServiceTest() {
        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();
        System.out.println("singletonService1 = " + singletonService1);
        System.out.println("singletonService2 = " + singletonService2);
 
        assertThat(singletonService1).isSameAs(singletonService2);
    }
}

 

싱글톤 패턴 문제점

1. 싱글톤 패턴을 구현하는데 많은 코드를 작성해야한다.
2. 의존관계상 클라이언트가 구체 클래스에 의존한다. ( = DIP를 위반한다. 역할에만 의존해야하는데 구체 클래스에 의존했으니 DIP 위반)

클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다. 테스트하기 어렵다.
3. 내부 속성을 변경하거나 초기화 하기 어렵다.
4. private 생성자로 자식 클래스를 만들기 어렵다.

 

결론적으로 유연성이 떨어진다.
안티패턴으로 불리기도 한다.

 

해결 : 스프링 컨테이너를 사용하면 스프링 빈 자체가 싱글톤으로 관리된다.

 

 

2. 싱글톤 컨테이너

 

스프링 컨테이너에서 싱글톤 패턴

스프링 컨테이너에 빈 객체를 등록하면, 위 코드처럼 복잡하게 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.

덕분에 싱글톤의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

 

// AppConfig.java
@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    
    ...
}


// SingleTonTest.java
public class SingletonTest {
 
    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void springContainer() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);
 
        assertThat(memberService1).isSameAs(memberService2);
    }
 
}

AnnotationConfigApplicationContext 를 통해 스프링 컨테이너 방식으로 memberService 라는 이름의 빈을 2번 생성했고, assertThat() 의 결과 두 객체는 (memberService1, memberService2) 결국 같다는 것을 확인할 수 있다.

 

이전에 싱글톤 패턴을 적용하기 위해서는 private 접근 제어자를 선언하는 등 별도의 작업이 많이 필요했지만, 스프링 컨테이너를 사용하면 별도 작업없이 싱글톤을 유지할 수 있다.

 

 

싱글톤 패턴의 주의점

싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에, 상태를 유지(stateful) 하도록 설계하면 안된다. 즉 싱글톤 객체는 stateless 하게 관리해야한다.

 

1. 무상태로 설계할 것
2. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
3. 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야한다.
4. 스프링 빈의필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다.

 

예시를 통해 확인해보자. 

 

아래 StatefulService 의 order() 메서드 내부에서 price 값을 변경할 수 있는 지점이 있다.

order() 메서드의 책임은 그저 어떤 name 의 상품을 얼마의 price 로 주문했음을 출력하는 데서 끝나야한다.

하지만 this.price = price 코드에서 해당 필드 값을 변경해버리기 때문에 문제 유발의 가능성을 지니게 됐다.

// StatefulService

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;
    }
}

 

그렇기 때문에 테스트코드에서 싱글톤 객체가 서로 다른 price 값을 매개변수로 받더라도, 두 객체가 리턴하는 getPrice() 의 값은 같게 된다.

// StatefulServiceTest

public class StatefulServiceTest {
    @Test
    void statefulServiceSingleton() {
 
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);
 
 
        // Thread A : A 사용자 10000원 주문
        statefulService1.order("userA", 10000);
 
        // Thread B : B 사용자 20000원 주문
        statefulService2.order("userB", 20000);
 
        int price = statefulService1.getPrice();
        System.out.println("price = " + price); // 10000 을 기대했지만, 20000 이 나온다.
        assertThat(price).isNotEqualTo(10000);
        assertThat(statefulService1).isSameAs(statefulService2);
    }
}

 

마지막 줄의  assertThat(statefulService1).isSameAs(statefulService2) 코드가 통과되면서 statefulService1 과 statefulService2 는 같은 객체임을 확인할 수 있다.

 

따라서 StatefulService 코드는 아래처럼 stateless 하게 설계하는 것이 옳다.

public class StatefulService {
    private int price;
 
    public int order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        // wrong
        // this.price = price;
        
        // right
        return price;  // 값 할당이 아닌 곧바로 리턴하도록 수정
    }
 
    public int getPrice() {
        return price;
    }
}

 

결론 

공유 필드는 항상 조심해야하며, 스프링 빈은 stateless 하게 설계해야한다.

 

 

3. @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() 를 호출한다.

 

결과적으로 각각 다른 MemoryMemberRepository 가 두번 생성되면서 싱글톤이 깨지는 것 처럼 보인다.

테스트 코드를 통해 두 객체가 실제로 다른지 확인해보자. 

public class ConfigurationSingletonTest {
 
    @Test
    @DisplayName("서로 다른 빈 객체에서 생성한 하나의 객체는 동일한가?")
    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);
        // 서로 다른 bean 객체로부터 MemberRepository 를 호출
        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();
 
        System.out.println(memberRepository1 == memberRepository2 && memberRepository == memberRepository2);
        // 결국 모두 같은 주소값을 공유하기에, 동일한 객체로 볼 수 있다.
 
        Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository); // 같다
        Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);  // 같다
    }
}


@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();
    }
}

출력문을 삽입하여, 각각 객체가 몇번 실행되는지 확인해보자. 

 

가정

>>> memberService 스프링 빈 생성할 때

"call AppConfig.memberService"
"call AppConfig.memberRepository"

 

>>> orderService 스프링 빈 생성할 때
"call AppConfig.orderService"
"call AppConfig.memberRepository"

 

>>> memberRepository 스프링 빈 생성할 때

"call AppConfig.memberRepository"

------------------------------------------

동일한 memberRepository 가 세번 출력될 것으로 예상

 

 

실제 검증

예상과 다르게 memberRepository 는 한번만 출력된 것을 확인할 수 있다.

 

그렇다면 왜 중복되는 인스턴스는 한번만 호출되는 것일까?

왜냐하면 @Configuration 어노테이션이 붙으면 CGLIB 이라는 바이트코드 조작 라이브러리가 동작하기 때문이다.

코드로 더 자세히 알아보자. 

public class ConfigurationSingletonTest {
  
    @Test
    void configutationDeep() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        
        AppConfig bean = ac.getBean(AppConfig.class);
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);

        System.out.println(" bean = " + memberService.getClass());
        System.out.println(" bean = " + bean.getClass());
    }
}

두번째 출력문의 결과를 예상하면 bean = class hello.core.AppConfig 이 나와야한다.

왜냐하면 첫번째 출력문의 결과는 bean = class hello.core.member.MemberServiceImpl 이기 때문이다.

 

하지만 실제 콘솔에 찍힌 결과를 확인하면,

 

AppConfig 뒤에 부가적인 정보가 붙어 출력된다. 그리고 해당 부가 정보를 잘 읽어보면 GCLIB 이라는 문자를 확인할 수 있다. 

결론부터 이야기하면 CGLIB (라이브러리)가 개입한 것이고, 왜 개입했냐하면 AppConfig 클래스는 @Configuration 어노테이션이 붙기 때문이다.

예상한 결과와 달리 부가 정보가 붙었다는 것은 개발자가 직접 생성한 클래스가 아닌, CGLIB 라이브러리가 AppConfig 클래스를 상속받아 임의의 클래스를 만들어 스프링 빈으로 반환한 것이다.

 

 

본론으로 돌아와 우리는 memberRepository 라는 중복된 인스턴스가 왜 한번만 호출되는지 추론할 수 있게 됐는데, 바로 AppConfig@GCLIB 이라는 CGLIB 라이브러리를 통해 생성된 임의의 클래스가 바이트코드를 조작하여 MemberRepository 의 싱글톤을 보장해주기 때문이다. (실제로 CGLIB 의 내부 기술을 사용하는 것은 매우 복잡하다고 한다.)

 

 

결론

@Bean 어노테이션만 사용하면 스프링 빈으로 등록되지만, 싱글톤을 보장받지 못한다. 싱글톤이 보장되는 이유는 스프링 컨테이너에 @Configuration 어노테이션이 있기 때문이다. (그러므로 스프링 설정 정보 클래스엔 항상 @Configuration 을 붙일 것)