클래스의 인스턴스가 딱 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("싱글톤 객체 로직 호출");
}
}
getInstance()
메서드를 통해서만 조회할 수 있다.참고로 싱글톤 패턴을 구현하는 방법은 여러가지가 있다. 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했다.
싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 다음과 같이 여러가지 문제점들을 가진다.
그런데 중간에 우리 했듯이 AppConfig같은 IoC 컨테이너를 두면 싱글톤도 DIP 위반 문제 해결되지 않나? 아래에 나와 같은 의문을 가진 분이 질문을 하였고 그에대한 답을 해주셨다.
스프링 컨테이너는 싱글턴 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.
참고로 스프링의 기본 빈 등록방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아니다. 요청할 때마다 새로운 객체를 생성해서 반환하는 기능도 제공한다 (prototype scope, 웹 관련 scope 등)
싱글톤 객체는 전역에서 공유되는 객체이므로 멀티쓰레드 환경에서의 동시성 문제를 해결해야한다.
전역에서 공유된다는 것, 메모리 영역에서 프로세스 전체에서 공유된다는 것. (생성된 인스턴스는 JVM 메모리의 힙영역에 할당되니까!)
개별 쓰레드당 할당되는 것이 아니라는 것!
공유변수의 동시성 문제는 OS에서도 나오는 중요한 개념!
둘 이상의 스레드가 동시에 공유변수 (임계구역)에 접근할 때 발생하는 문제들이 많으므로 상호배제를 보장해주어야함!
아니면 아예 상태를 유지하지 않도록 설계해라! 공유하는 값이 없도록!
(static 변수나 멤버변수에 값을 유지하고 있지 않도록 설계 : stateless)
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 StatefulTest {
@Test
void statefulServiceSingleton() {
ApplicationContext = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService2 = ac.getBean("statefulService", StatefulService.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원 출력
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
}
static class TestConfig {
@Bean
public StatefulService statefulService {
return new StatefulService();
}
}
@Configuration
은 사실 싱글톤을 위해 존재한다
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
}
memberRepository()
를 호출new MemoryMemberRepository()
호출memberRepository()
를 호출new MemoryMemberRepository()
를 호출결과적으로 각각 다른 2개의
MemoryMemberRepository
가 생성되면서 싱글톤이 깨지는 것처럼 보인다. 스프링 컨테이너는 어떻게 이 문제를 해결하는 것일까?
memberRepository
빈은 모두 같은 인스턴스를 참조하는 것을 알 수 있다.스프링 컨테이너는 싱글톤 레지스트리이다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야한다. 그런데 스프링이 자바 코드까지 어떻게 할 수는 없다. 위의 자바 코드를 보면 분명 3번 호출이 되어야하는데, 한 번만 호출되고있다.
스프링은 이를 위해 클래스의 바이트 코드를 조작하는 라이브러리를 사용한다.
모든 비밀은 @Configuration
을 적용한 AppConfig
에 있다.
@Test
void configurationDeep() {
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
//AppConfig도 스프링 빈으로 등록된다.
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean.getClass());
// 출력: bean = class hello.core.AppConfig$$EnhancedBySpringCGLIB$$bd479d70
}
AnnotationConfigApplicationContext
의 파라미터로 넘긴 값도 스프링 빈으로 등록된다. 따라서 AppConfig
도 스프링 빈이 된다.AppConfig
스프링 빈을 조회해서 클래스 정보를 출력해보자bean = class hello.core.AppConfig$$EnhancedBySpringCGLIB$$bd479d70
만약 순수한 자바 클래스라면 아래와 같이 출력되어야한다.
class hello.core.AppConfig
그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 복잡한 이름을 갖게된 것을 알 수 있다.
이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록했기 때문이다.
이름은 appConfig 이름을 가져가고, 실제 등록되는 스프링 빈은 @CGLIB 클래스의 인스턴스가 등록된다.
스프링이 CGLIB 바이트코드 조작 라이브러리를 사용하여 만든 클래스가 바로 스프링 빈이 싱글톤이 보장되도록 해준다. 아마도 다음과 같이 바이트 코드를 조작해서 작성되어있을 것이다. (실제로는 CGLIB의 내부 기술을 사용하는데 매우 복잡하다.)
@Bean
public MemberRepository memberRepository() {
if(memorymemberRepository가 이미 스프링 컨테이너에 등록되어있으면?) {
return 스프링 컨테이너에서 찾아서 반환;
} else { // 스프링 컨테이너에 없으면
기존로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
return 반환;
}
}
참고로 AppConfig@CGLIB은 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회 가능하다. (부모타입으로 빈 조회하면 자식 타입 빈들까지 다 조회하니까!)
@Configuration
을 붙이면 바이트 코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean
만 적용하면 어떻게 될까?
@Configuration
을 주석처리 한 후 테스트를 다시 실행해보자!
결론부터 말하면, 스프링 빈이 등록되긴 한다. 하지만, CGLIB으로 바이트코드 조작되어 싱글톤을 보장하는 빈이 등록되지 않고, 순수 자바 객체가 등록된다. (싱글톤 보장 X)
무슨 문제가 있을까?
스프링 빈 등록시 아까와 다르게 memberRepository가 3번 호출된다!!
memberService와 orderService에 주입되는 memberRepository 객체는 스프링에 등록된 빈 객체가 아닌, 메서드 호출로 새로 생성된 인스턴스가 주입된다.😫 (스프링 컨테이너가 관리하지 않는 객체다)
@Bean
만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.@Configuration
없이 사용한다면 memberRepository()
처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.@Configuration
을 사용하자!!해당 게시글은 인프런 김영한님의 <스프링 핵심 원리 - 기본편>을 듣고 정리한 내용입니다.