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

웹 애플리케이션과 싱글톤

웹 애플리케이션은 보통 여러 사용자가 동시에 요청을 함 

동시 요청시 때 마다 매번 객체를 생성하지 않음 

 

순수한 DI 컨테이너는 객체를 호출할 때 마다 계속해서 생성 

=> 과도한 트래픽이 발생할 경우 메모리 낭비 심함 

=> 싱글톤을 이용해 1개만 생성하여 공유 하도록 함 

 

싱글톤 패턴

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

일반적으로 static 영역에 instance를 미리 하나 생성하여 올려두고 getter를 통해서만 받을 수 있게 한다. 혹시라도 생성하지 못하게 생성자는 private으로 막는다.

스프링 컨테이너는 모든 빈 객체를 싱글톤 패턴으로 관리 함

 

#문제점

구현하는데 코드 자체가 많이 들어감

DIP 위배 (구체 클래스에 의존)

OCP 위배할 가능성 존재 

테스트하기 어려움

내부속성 변경하거나 초기화 어려움

private 생성자로 인해 자식 클래스 생성 어려움

=> 유연성 떨어짐

=> 스프링 컨테이너가 해당 문제들 해결

 

싱글톤 컨테이너

스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리

=> 싱글톤 레지스트리

=> 문제점 해결(구현코드 간결, 자유롭게 싱글톤 사용 가능)

 

싱글톤 주의점

특정 클라이언트에 의존적이거나 값을 변경할 수 있으면 안됨

=> 값을 변경할 경우 데이터 불일치 발생 

read만 가능하게 해야 함

 

@Configuration

AppConfig는 스프링이 바이트코드 조작 라이브러리를 사용해 AppConfig를 상속받은 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록 

=> 해당 클래스가 싱글톤이 보장되도록 해 줌

 

@Bean 어노테이션이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고 없으면 생성 후 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어짐

=> 싱글톤이 보장 됨

 

@Configuration 어노테이션을 사용하지 않을 경우 바이트코드 조작 라이브러리를 사용해 AppConfig를 상속받은 다른 클래스를 만들지 않고 AppConfig를 그대로 사용함 

=> 싱글톤 보장 안됨 (객체들이 계속 생성)

 

 

 

 

출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8