[Spring] Section5_싱글톤 컨테이너

인프런

스프링 핵심 - 기본편

김영한

---

Section5_싱글톤 컨테이너

• 웹페이지는 동시에 클라이언트가 접속 → 스프링 없는 순수한 DI 컨테이너(AppConfig)는 요청할 때마다 객체를 새로 생성함.
• solution) 객체가 1개만 생성되고 공유되도록 설계해야 함. → “싱글톤 패턴”

​

싱글톤 패턴

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

• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하게 막아야 함.
• static 사용 → 싱글톤 패턴
  • 이 객체 인스턴스가 필요하면 getInstance() 메서드를 통해서만 조회할 수 있음. → 이 메서드를 호출하면 항상 같은 인스턴스 반환.
  • 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막음.
• 싱글톤 패턴 구현 방법은 다양함. 그러므로, 싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있음.(하지만 문제가 많다.)
  • 문제점 → 코드 양이 많아짐, DIP 위반, OCP 위반, 테스트가 어려움, 내부 변경 및 초기화가 어려움, private 사용으로 자식클래스를 만들기 힘듦, 유연성이 떨어짐.
  • 이에 대한 해결책이 싱글톤 컨테이너(=스프링 컨테이너)

​

싱글톤 컨테이너(스프링 컨테이너)

: 싱글톤 패턴의 문제점을 해결, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리함.

• 스프링 빈 : 싱글톤으로 관리되는 빈
• 싱글톤 레지스트리 : 싱글톤 객체를 생성하고 관리하는 기능
• 싱글톤 패턴의 모든 문제점 해결

​

싱글톤 방식의 주의점

• 클라이언트들이 하나의 객체 인스턴스를 공유하므로 상태를 유지(stateful)하게 설계하면 안됨.
• 무상태(stateless)로 설계해야 함.
  • 특정 클라이언트에 의존적 필드X.
  • 가급적 읽기만 가능해야 함.
  • 필드 대신 자바에서 공유되지 않는 지역 변수, 파라미터, ThreadLocal 등을 사용해야 함.
  • 단, 공유 필드(변수)는 조심해야 함. 스프링 빈은 항상 무상태로 설계

​

@Configuration 과 싱글톤

• @Configuration : 메소드 호출 시 싱글톤 보장함. (같은 메서드를 1번만 호출)
• AppConfig : 내가 만든 클래스X, 스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속 받은 임의의 다른 클래스를 만듦. 그 클래스를 스프링 빈으로 등록.
• @Bean 이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환함. 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어짐.
• @Configuration 어노테이션이 없어도 @Bean 이 스프링 빈으로 등록은 되지만, 싱글톤은 보장X.

​

객체 vs 인스턴스

객체

: 속성과 행위(기능)을 가짐.

• 구현할 대상
• 속성은 필드(변수), 행위는 메서드

인스턴스

: 클래스를 통해 생성된 객체를 클래스의 인스턴스라 함.

• 구현된 구체적 실체
• 클래스의 타입으로 선언되었을 때 “객체”, 그 객체가 메모리에 할당되어 실제로 사용될 때 “인스턴스”

​

Thread

: 하나의 프로세스 내에서 여러 개의 실행 흐름(단일, 동시, 병렬)을 두어 작업을 효율적으로 처리하기 위한 모델.