스프링 싱글톤 컨테이너

웹 어플리케이션과 싱글톤

---

• 웹 어플리케이션은 보통 고객이 여러명
• 기존 스프링 없는 DI 컨테이너는 고객이 service를 요청할 때마다, service 객체가 생성되게 된다.

@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer(){
    AppConfig appconfig = new AppConfig();

    // 1. 조회
    MemberService memberService1 = appconfig.memberService();

    // 2. 조회
    MemberService memberService2 = appconfig.memberService();

    assertThat(memberService1).isNotSameAs(memberService2);
}

해결 방법 : 해당 객체를 딱 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("싱글톤 객체 로직 호출");
	}
}

싱글톤 패턴의 장점

• 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 사용

싱글톤 패턴의 단점

• 객체를 싱글톤으로 만들기 위한 코드가 많이 들어간다.
• 의존관계 상 클라이언트가 구체 클래스에 의존 → DIP위반, OCP위반 가능성 상승
• 테스트하기가 어렵다 → 프로그램이 올라갈 때 객체가 생성되기 때문에
• 내부 속성을 변경하거나 초기화하기 어렵다 → 프로그램이 올라갈 때 객체가 생성되기 때문에
• 자식 클래스를 만들기 어렵다. → private 생성자이기 때문

 

싱글톤 컨테이너

---

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리

• 싱글톤 패턴을 위한 별도의 코드를 생성하지 않아도 됨
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용 가능

싱글톤 컨테이너 적용 후

• 요청할 때마다 새로운 객체를 생성해서 반환하는 기능도 제공

 

싱글톤 방식의 주의점

---

• 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유
• 따라서 싱글톤 객체는 상태를 유지(stateful)하게 설계 X
• 무상태(stateless)로 설계해야 한다.
  • 특정 클라이언트에 의존적인 필드 존재 X
  • 특정 클라이언트가 값을 변경할 수 있는 필드 존재 X
  • 가급적 읽기만 지원
  • 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, threadLocal 등을 사용
• 스프링 빈의 필드에 공유값을 설정하면 큰 장애가 발생할 수 있다.

잘못된 코드

public class StatefulService {
    private int price;

    public void order(String name, int price){
        this.price = price; // 문제!
    }

    public int getPrice() {
        return price;
    }
}

• Service에서 공유필드 price를 사용
• price 필드값을 클라이언트가 변경 가능

void statefulServiceSingleton(){
    statefulService1.order("UserA", 1000);
    statefulService2.order("UserB", 2000);

    int price = statefulService1.getPrice();
    System.out.println("price = " + price); // 원하는 것 : 1000, 나온 것 : 2000
}

• 서로 다른 service에서 order를 넣고, 자신의 결제 금액을 확인하는데, Service가 싱글톤이기 때문에 다른 사람의 결제 내역이 보일 수 있다.

수정된 코드

public class StatefulService { 
    public int order(String name, int price){
        // 로직 코드
        return price;
    }
}

• 공유필드 사용 X
• 클라이언트가 값을 변경할 수 없도록 수정

 

@Configuration

---

• 기존 AppConfig를 보면, 하나의 객체가 여러번 생성되는 것을 볼 수 있다.
• 이러한 것들에 대해서도 싱글톤을 보장해주기 위해 @Configuration을 사용
• CGLIB이라는 바이트코드 조작 라이브러리를 사용해 AppConfig를 상속받은 임의의 다른 클래스를 만들어서 빈에 등록

Appconfig@CGLIB 예상 코드

따라서 @Configuration이 붙어있지 않다면, 객체를 싱글톤으로 생성하지 않는다.