4. 싱글톤 컨테이너

이 포스팅은 인프런에 있는 김영한 강사님의 스프링 핵심 원리 강의를 들으며 개인 공부를 한 것입니다.
소스코드는 제가 직접 작성하였습니다. (참고 : 깃허브주소)

✅ 웹 애플리케이션과 싱글톤

• 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
  • 한 사람당 하나의 서비스를 매번 호출하게 되는 격.
  • 서비스는 하나만 올라와 있어도 여러 사람이 호출해서 사용하면 됨.
• 요청할 때마다 객체를 새로 생성하면 메모리 낭비가 심하다
  • 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다
• 해결방법 : 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다 -> 싱글톤 패턴

✅ 싱글톤 패턴

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다
  • private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다

✅ 싱글톤 컨테이너

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다
  • DIP∙OCP 위반, 테스트하기 어려움 , private 생성자로 자식 클래스를 만들기 어려움 등등 단점이 해결된다
• 스프링 컨테이너 덕분에 객체를 매번 생성하는 것이 아니라 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.

✅ 싱글톤 방식의 주의점

• 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다
• 스프링 빈은 항상 무상태(stateless)로 설계해야 한다
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다
  • 가급적 읽기만 해야한다
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야한다
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다

public class StatefulService {  

    private String msg; // 상태를 유지하는 필드  
    public void send(String msg) {  
        System.out.println("msg = " + msg);  
        this.msg = msg; // 여기가 문제!  
    }  

    public String getMsg() {  
        return msg;  
    }  
}

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사용자 문자 "안녕하세요" 보냄  
        statefulService1.send("안녕하세요");  

        //ThreadB : B사용자 문자 "안녕히 계세요" 보냄  
        statefulService2.send("안녕히 계세요");  

        // ThreadA 문자 내용 조회  
        // "안녕하세요" 를 기대했지만, 기대와 다르게 "안녕히 계세요" 출력  
        String msg = statefulService1.getMsg();  
        System.out.println("msg = " + msg);  

        Assertions.assertThat(statefulService1.getMsg()).isNotEqualTo("안녕하세요");  
    }  

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

1. TestConfig에 @Configuration을 붙이지 않아도 스프링 컨테이너 생성 시 파라미터로 설정정보를 넘길 때, @Bean 어노테이션이 있으면 빈으로 등록이 된다
   • new AnnotationConfigApplicationContext(TestConfig.class);
2. @Configuration을 붙이지 않아도 스프링 컨테이너로 설정정보를 넘기면 해당 설정파일은 싱글톤으로 관리된다. 하지만 해당 클래스 내에서 사용되는 메서드 안의 객체들에 대해서는 싱글톤을 보장하지 않는다

✅ @Configuration

• AppConfig 스프링 빈을 조회해서 클래스명을 출력해보면 xxxCGLIB이라고 클래스명이 붙어서 출력된다
• 그 이유는 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이기 때문이다.
• 그 임의의 다른 클래스가 싱글톤이 보장되도록 해준다. (껍데기 클래스)
  • @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다
• @Configuration이 선언된 클래스에서는 @Bean뿐만 아니라 의존관계를 주입하는 객체도 싱글톤을 보장해준다
• 즉, @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다
• 스프링 설정 정보는 항상 @Configuration을 사용하자

@Configuration을 적용하지 않고 @Bean만 적용하면 어떻게 될까?

• CGLIB 기술 없이 순수한 AppConfig로 스프링 빈에 등록이 된다
• 호출하는 횟수대로 계속 호출된다
  • 파라미터의 객체들에 대해서는 싱글톤을 보장하지 않기 때문
  • return new SmsServiceImpl( smsRepository(), custRepository(), smsFilter() )
    );

✅ 결론

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