[인프런]스프링 핵심원리 기본편_싱글톤 컨테이너

싱글톤 패턴

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

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하기 위해 사용하는 코드가 많다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. 이 때문에 DIP를 위반하고, OCP 원칙 위반의 가능성 또한 높다.
• 테스트가 어렵다.
• 내부 속성의 변경 혹은 초기화가 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 아처럼 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 스프링 컨테이너의 이러한 기능 덕분에 싱글톤 패턴의 모든 단점들을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 컨테이너 적용 후

• 스프링 컨테이너를 사용하면 고객의 요청이 올 때마다 객체를 생성하지 않고 이미 만들어진 객체를 사용해서 효율적으로 재사용할 수 있다.

 

※ 싱글톤 방식의 주의점

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

@Configuration 과 싱글톤, 바이트코드 조작

• 예제 코드에 System.out.println() 을 보면, @Bean > memberRepository 에 대한 출력문이 3번이 호출되어야 한다. 그러나 결과를 보면 1번만 호출되었다.
• 그 이유는 바로 @Configuration 에 있다.
• 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 클래스를 스프링 빈으로 등록한다.

• CGLIB의 예상 코드를 추측해보자면, @Bean이 붙은 메소드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드일 것이다.
• 이 덕분에 싱글톤이 보장된다.
• AppConfig@CGLIB 는 AppConfig의 자식 타입으로, AppConfig 타입으로 조회할 수 있다.
• @Configuration 을 제거하면 싱글톤이 깨진다.

---

해당 글은 인프런 > 스프링 핵심 원리 기본편(김영한)강의를 참고하여 작성하였습니다.