[2024-2 Spring Boot 스터디] 김문기 #5주

section 6

if 만약 우리가 스프링 없이 순수한 DI 컨테이너를 통해 애플리케이션을 생성했다면?

위와 같이 각 고객이 요청을 보낼 때마다 객체가 생성된다.
따라서 우리는 객체를 딱 1번만 생성되게 하고 공유하게 해야한다. => 이러한 방식을 싱글톤 패턴이라고 한다.

 

싱글톤 패턴

 public class SingletonService {
	 //1. static 영역에 객체를 딱 1개만 생성해둔다.
 	private static final SingletonService instance = new SingletonService();
 	//2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한
다.
	 }

 	public static SingletonService getInstance() {
 		return instance;
  	  }
	 //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
 	private SingletonService() {
   	 }
 	public void logic() {
 	System.out.println("싱글톤 객체 로직 호출");
    	}
  }

• 영역 전체에 instance를 하나만 생성한다,
• new 키워드를 통해 새로운 객체 인스턴스가 생성되는걸 막아야 한다.

# 결론: 싱글톤 패턴을 적용 함으로서 한번 만들어진 객체를 공유해서 여러 객체가 생기면서 생기는 메모리 낭비 등 여러가지 문제를 없앨 수 있다.

 

이러한 싱글톤 패턴에도 문제가 있다.

• 의존 관계상 클라이언트가 구체 클래스에 의존하게 된다, => 따라서 DIP를 위반하게 된다.
• 같은 이유로 OCP 원칙을 위반할 가능성이 높아진다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어진다.

 

이러한 싱글톤 패턴의 문제점을 해결하기 위해 사용되는 것이 싱글톤 컨테이너 이다.

 

싱글톤 컨테이너

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리해 준다.
• 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

 

 

싱글톤 방식의 주의점

1. 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다.
2. 무상태로 설계해야 한다. => 특정 클라이언트에 의존적인 필드가 없어야 한다, 특정 클라인언트가 값을 변경할 수 있는 필드가 있으면 안된다

 

@Configuration

우리는 이렇게 스프링 빈이 싱글톤이 되도록 해주어야 하는데 이를 위해 사용하는 것이 @configuration 어노테이션이다.

 

@Configuration 어노테이션을 사용 하면 우리가 만든 설정 파일(Appconfig)를 상속 받는 CGLIB 이라는 바이트 코드 조작 라이브러리를 만들게 된다. 그리고 스프링은 이 클래스를 스프링 빈으로 등록 하므로써 싱글 톤이 보장 되도록 해주는 것이다.

 

만약 @Configuration을 사용하지 않고 @Bean만 사용한다면?

@Bean 어노테이션 만을 사용한다면 스프링 빈으로 등록은 할 수 있겠지만 싱글톤을 보장 할 수 없다.
즉 우리가 짠 코드의 memberRepository처럼 의존관계 주입이 필요해서 해당 메소드를 호출할 때 싱글 톤을 보장 할 수 없다는 것이다.

 

# 사실 이런 문제점을 해결 하기 위해 @Autowired 라는 어노테이션을 사용 할 수 있다.

예를 들어 

@Autowired MemberReposiroy memeberRepository

위와 같이 작성을 해주면 자동으로 의존관계가 주입 되므로 싱글톤을 유지 할 수 있다.