스프링 핵심 원리 - 싱글톤 컨테이너, @Configuration
싱글톤 패턴
- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
private생성자를 사용해서 외부에서 임의로new키워드를 사용하지 못하도록 막는다.
package hello.core.singleton;
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("싱글톤 객체 로직 호출");
}
}싱글톤 패턴의 단점
- 싱글톤 패턴을 규현하는 코드 자체가 많이 들어간다.
- 의존 관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
- 클라이언트가 구체 클래스에 의존해서 OCP 위한할 가능성 높음
private생성자로 자식 클래스를 만들기 어려움- 유연성이 떨어져서 안티패턴으로 불리기도 함
싱글톤 컨테이너
- 스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리해준다.
- 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
- 싱글톤 레지스트리 덕분에 싱글턴 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지가 가능하다.
- DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.
싱글톤 방식의 주의점
- 싱글톤 방식은 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계 하면 안된다.
- 무상태로 설계 해야한다.
package hello.core.singleton;
public class StatefulService {
private int price; //상태를 유지하는 필드
public int order(String name, int price){
System.out.println("name = " + name + "price = "+price);/ this.price = price; //여기가 문제!
this.price = price; **//여기가 문제!! -> 상태를 유지하게 설계됨**
}
public int getPrice() {
return price;
}
}- StatefulService의 price필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.
package hello.core.singleton;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
public class StatefulServiceTest {
@Test
void statefulServiceSingleton() {
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean(StatefulService.class);
StatefulService statefulService2 = ac.getBean(StatefulService.class);
//ThreadA : A사용자 10000원주문
statefulService1.order("userA", 10000);
//ThreadA : B사용자 20000원주문
statefulService2.order("userB", 20000);
//ThreadA: 사용자A 주문 금액 조회
int price = statefulService1.getPrice();
//ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
System.out.println("price = " + price);
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
static class TestConfig{
@Bean
public StatefulService statefulService() {
return new StatefulService();
}
}
}
- 사용자 A가 10000원을 주문하고, 조회하기전에 사용자 B가 20000원을 주문하면,
this.price = price;때문에 A가 주문을 조회 했을때, 10000원이 아닌 20000원이 나온다. →price필드를 공유하는 설계 때문! - 스프링 빈은 항상 무상태(stateless)로 설계 해야 한다!
@Configuration과 바이트 코드 조작
@Configutration: 설정파일을 만들기 위한 애노테이션 orBean을 등록하기 위한 애노테이션이다.@Configuration을 적용한AppConfig는 바이트 코드를 조작한CGLIB라는 라이브러리를 사용해서AppConfig클래스를 상속받은 임의의 클래스를 만들고 그것을 스프링 빈으로 등록 해준다.
@Configuration을 사용하지 않고,@Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤은 보장 되지 않는다.- 스프링 설정 정보에
@Configuration을 사용하면 싱글톤을 보장받을 수 있다.
반응형