[Spring] 핵심 원리 기본 (5) - 싱글톤 컨테이너

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

• 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
• 스프링 없는 순수 DI 컨테이너인 AppConfig는 요청이 들어올 때마다 객체를 새로 생성한다. → 메모리 낭비 심함
• 해결 방안은 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 된다. → 싱글톤 패턴

 

📌 싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감
• 의존관계상 클라이언트가 구체 클래스에 의존함 → DIP 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음
• 테스트 하기 어려움
• 내부 속성을 변경하거나 초기화하기 어려움
• private 생성자로 자식 클래스를 만들기 어려움
• 결론적으로 유연성이 떨어짐

 

📌 싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스(스프링 빈)를 싱글톤으로 관리한다.
• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

 

📌 싱글톤 적용 후 

• 스프링 컨테이너 덕분에 고객의 요청이 올때마다 객체를 생성하는 것이 아니라 이미 만들어진 객체를 공유하여 효율적으로 재사용할 수 있다.

 

📌 싱글톤 방식 주의점

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

 

📌 스프링 컨테이너가 싱글톤 빈을 보장하는 원리

• 스프링은 클래스의 바이트 코드를 조작하는 라이브러리(CGLIB)를 사용하여 @Configuration을 적용한 AppConfig를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한다.
• 이 임의의 다른 클래스가 싱글톤이 보장되도록 해준다.
• 빈을 등록할 때 빈이 이미 존재하면 존재하는 빈을 가져오고, 없다면 생성해서 스프링 빈으로 등록하고 반환한다.
• 만약 설정정보에 @Configuration을 적용하지 않고 @Bean을 사용하면 스프링 빈으로 등록되지만 싱글톤을 보장하지는 않는다.

 

---

강의 링크

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