[스프링 핵심] 싱글톤 컨테이너

웹 앱은 보통 여러 고객이 동시에 요청을 한다. 스프링은 기업의 웹 앱을 지원하기 위해 탄생했다.

그러니까 스프링은 여러 고객의 동시요청에 잘 리액션하게끔 만들어진 것이다.

 

스프링이 없이 순수 JAVA만으로 만들면, 필연적으로 new를 쓰게 되고, 고객 요청 시마다 new를 쓰니까 그 횟수만큼 새로운 애들이 만들어진다.

 

그러니까 순수 JAVA의 경우에는, 만약 고객 트래픽이 초당 100이 나오면 초당 100개의 객체가 생성괴고 소멸된다.

=> 메모리 낭비가 심하다. => 해당 객체를 하나만 생성하고, 공유하도록 설계하면 된다 ( <= 싱글톤 패턴 )

 

싱글톤 패턴

- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

- 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다

 

* private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 함.

* 잘 설계한 객체는 compile 단에서 에러가 나버리게 하는 게 좋은 설계다.

 

=> 이건 그냥 보여주기용으로 만든 거고, Spring은 이미 싱글톤을 자체적으로 구현하기 때문에 저런 구현이 필요없다.

 

그러나 싱글톤 패턴은 기본적으로 여러 개의 문제를 가지고 있다.

 

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. => DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다. DI를 구현하기 어렵다.
• 안티패턴으로 불리기도 한다.

 

싱글톤 컨테이너

그런데 Spring에서는 자체적으로 만드는 싱글톤 컨테이너에서, 싱글톤 패턴의 고유적인 문제를 해결하면서 싱글톤 패턴을 사용한다. 그래서 대-단하다는 거다. 그렇게 컨테이너에 싱글톤이 적용된 스프링의 컨테이너는 이렇게 된다.

 

 

★☆★ 싱글톤 방식 (싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너든) 의 주의점

싱글톤 방식은, 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 무조건 stateless로 설계해야 한다.

• 특정 클라이언트에 의존적인 필드가 없어야 한다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 없어야 한다.
• 읽기만 가능한 것을 원칙으로 한다.
• 필드 대신에 자바에서 공유 안되는 것들 - 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

만약 이렇다면, price라는 값을 수정할 수 있게 되어있으므로 저 둘이 상충되어 꼬이는 현상이 발생한다.

이렇게 설계된 걸 stateful이라고 한다. spring bean은 무조건 stateless로 만들어야 한다.

위의 경우에, price라는 걸 아예 만들지를 말아야 한다. 그 안에 값을 저장할게 아니라, 외부에 저장하여 리턴시키도록 설계해야함을 잊지말자.

 

@Configuration과 싱글톤

JAVA 입장에서 보면 new 라는 키워드를 가지고 뭔가를 만드는 것이 반복되면, 두개 이상의 서로 다른 객체를 생성하여야 정상이다. 그러나 SPRING에서 그런 코드를 작성하면, SPRING이 알아서 중복을 확인하고 하나만 갖다 쓴다. 킹-프링!

 

스프링 컨테이너는 싱글톤 레지스트리기 때문에, 스프링 빈이 싱글톤이 되도록 보장되어야 한다. JAVA에서 혹여나 싱글톤 보장이 안 되게끔 하더라도, 스프링은 결국 싱글톤으로 거듭나게끔 한다. 그 방법은 바로 바이트코드 조작에 있다.

 

한마디로 우리가 빈에 대한 코드를 작성하고 실행하면, AppConfig을 토대로 실행이 그대로 되는 것이 아니라, 자동으로 xxxCGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 클래스를 스프링 빈으로 등록한다. 바로 그 녀석 CGLIB 뭐시기 그 녀석이 싱글톤이 가능하게끔 하는 것이다.

그 CGLIB는 Configuration에서만 적용된다.

 

그래서 기존에 있으면 그걸 그대로 반환해주고, 없으면 로직을 호출하는 것이다.

 

자, 그러면 만약 @Configuration 없이 그냥 @Bean만 써주면?

써도 1 스프링 빈으로 등록은 된다. 그러나 2 CGLIB 안 쓰기 때문에 싱글톤이 보장 안된다.

 

결론은, 스프링이 싱글톤을 지원한다는 것은 정확히 말하면 스프링 @Configuration이 싱글톤을 지원한다는 얘기다.

 

한마디로 Bean을 쓸때 @Configuration을 항상 사용하자!