1. 웹 애플리케이션과 싱글톤
- 웹 어플리케이션은 보통 여러 사용자가 동시에 요청을 한다. 물론 PC의 특성 상 완벽한 동시는 거의 불가능하다고 하지만 동시에 요청한다고 가정하자.
- 위 그림의 경우 클라이언트 A, B, C가 스프링 컨테이너(DI 컨테이너)에 요청을 하면 새로 new를 하여 반환하는 구조이다.
- 이렇게 동작한다면 요청이 올 때마다 새로운 구현 객체를 생성하므로 메모리 낭비가 발생한다.
* 싱글톤 패턴
- 싱글톤 패턴이란 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
- 인스턴스가 1개만 있어야 하므로 다른 클래스에서 생성하지 못하도록 막아야 한다.
- 즉 private 생성자를 사용하여 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.
- 아래 코드로 생성 예시를 보자!!
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("싱글톤 객체 로직 호출");
}
}- 객체를 새로 생성하는 것이 아니라 객체가 필요하면 getInstance()를 통해서 만들어 놓은 인스턴스를 반환한다.
* 싱글톤 패턴의 문제점
- 싱글톤 패턴을 구현하려면 코드 자체가 많이 들어간다.
- 의존 관계상 클라이언트가 구체 클래스에 의존하기 때문에 DIP를 위반한다.
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 테스트를 진행하기 까다롭다.
2. 싱글톤 컨테이너
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 기본으로 객체 인스턴스를 싱글톤으로 관리한다.
- 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
- 아래 그림은 싱글톤으로 동작하는 스프링 컨테이너의 그림이다.
- 기본적으로 싱글톤으로 동작하기 때문에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
2-1 싱글톤 방식의 주의점
- 앞서 스프링 컨테이너는 기본적으로 객체를 싱글톤으로 관리한다.
- 이런 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 유지 상태(stateful)로 설계하면 안되며 무상태(stateless)로 설계해야 한다.
* 무상태(stateless)
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
- 앞서 언급한 유지 상태를 예시 코드로 보자!
public class StatefulService {
private int price; //상태를 유지하는 필드
public void order(String name, int price) {
System.out.println("name = " + name + " price = " + price);
this.price = price; //여기가 문제!
}
public int getPrice() {
return price;
}
}public class StatefulServiceTest {
@Test
void statefulServiceSingleton() {
ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean("statefulService",StatefulService.class);
StatefulService statefulService2 = ac.getBean("statefulService",SatefulService.class);
//ThreadA: A사용자 10000원 주문
statefulService1.order("userA", 10000);
//ThreadB: 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 사용자가 2000원을 주문했다고 가정해보자.
- StatefulService의 price필드는 공유되는 필드이므로 A 사용자가 10000원을 주문한 다음 B 사용자가 20000원을 주문했기 때문에 A 사용자의 주문 금액을 출력해보면 10000원이 아니라 20000원이 출력된다.
- 항상 스프링 빈은 무상태(stateless)로 설계하자!!
2-2 @Configuration과 싱글톤
- @Configuration : 스프링 컨테이너에 등록되는 설정 정보 클래스를 의미하는 Annotation.
- 보통 스프링 컨테이너에 등록되는 설정 정보를 담고 있는 클래스에 붙여준다.
- 이 클래스를 AnnotationConfigApplicationContext에 넘겨주면 이 클래스를 보고 스프링 빈을 구성한다.
- 스프링 컨테이너는 클라이언트가 호출하는 스프링 빈이 이미 스프링 컨테이너에 있으면 그 빈을 반환하고, 없다면 새로 만들어서 반환한다.
- 설정 정보 클래스 정보를 출력해보자!! (설정 정보 클래스도 스프링 빈으로 등록되기 때문에 빈을 조회할 수 있다.)
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70- 만약 순수한 자바 클래스라면 다음과 같이 출력되어야 한다.
class hello.core.AppConfig- bean에 붙은 CGLIB는 무엇을 의미할까?
- 이는 바이트 코드 라이브러리이며 스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용하여 넘겨준 설정 정보 클래스를 상속받는 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다!!
- 만약 @Configuration을 적용하지 않고 @Bean (수동 빈)만 적용한다면 스프링 빈으로 등록은 되지만 싱글톤을 보장하지는 않는다.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
본 포스팅은 인프런의 '스프링 핵심 원리 - 기본편 : 김영한 강사님'의 강의와 자료를 참고하였습니다.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
