작년에 들었던 김영환님의 강의의
스프링 싱글톤 컨테이너에 대해서 복습 차원에서 정리하려고 한다.
1.싱글톤 패턴이란?
싱글톤 패턴이란 클래스의 인스턴스가 딱 1개만 생성되는것을 보장한는 디자인 패턴이다.
그렇기 때문에 싱글톤 패턴으로 지정된 클래스의 인스턴스는 2개이상 생성되는 방지하여야된다.
아래의 예시에서 싱글톤 패턴의 클래스를 생성해보겠다.
public class SingleTonService {
//해당 클래스를 생성하면 딱 하나로 자기자신을 참조하는 객체를 생성하여 가지고있는다. static로 선언하여 해당 클래스를 생성해도 해당 static변수는 하나만 생성되어 있다.
private static final SingleTonService singletonservice = new SingleTonService();
public static SingleTonService getInstance() {
return singletonservice;}
//외부에서 클래스 객체를 생성하지 못하도록 한다.
private SingleTonService() {}
public void logic(){
System.out.println("싱글톤 객체 로직 호출");
}
}Static를 사용하여 컴파일 후 자바가 실행될때 SingleTokenSevice클래스 인스턴스를 static영역에 올려두게 된다!getInstance()메서드를 통해 항상 같은 인스턴스(SingieTokenSevice)를 반환하게 된다.- 추가로 생성자를
private로 두어 외부에서 new로 객체 인스턴스를 생성하는것을 막아준다.
아래 Test코드를 통해 결과를 보게 되면 같은 객체 인스턴스가 반환되는것을 볼수 있다.
@Test
@DisplayName("스프링 없이 싱글톤 패턴을 적용한 객체 사용")
public void singleServiceTest() {
SingleTonService singleTonService1 = SingleTonService.getInstance();
SingleTonService singleTonService2 = SingleTonService.getInstance();
System.out.println("SingleTonService1: " + singleTonService1);
System.out.println("SingleTonService2: " + singleTonService2);
Assertions.assertThat(singleTonService1).isSameAs(singleTonService2);
}싱글톤 패턴을 적용하면 클라이언트의 요청이 올때마다 객체를 생성하는것이 아니라, 이미 만들어진 객체를 공유하여 사용할수 있게 된다.
하지만 싱글톤 패턴은 아래와 같은 문제점들을가지고 있다.
-
싱글톤 패턴을 구현하기 위해 코드 작성이 많아진다.
-> 위의 예시에서static,getInstance 메서드코드등 -
private 생성자를 사용하고 있기 때문에 상속에서 자식 클래스를 만들기 어렵다. -
SOLID원칙의 위반될 가능성이 있다.SOLID중DIP원칙은 추상화에 의존해야지, 구체화에 의존하면 안된다.
즉 의존성을 인터페이스에 두어 실제 구현한 클래스의 변경되어도 코드에 영향이없어야된다.
하지만 싱글톤에서는 구현 클래스를 미리 생성해놓기 때문에 해당 규칙을 위반한다.또한
SOLID중OCP원칙은 확장에는 열려있어야 하나, 변경에는 닫혀있어야한다.
싱글톤에서는 이미 구체 클래스를 생성하여 의존하고 있기 때문에 확장성이 어렵기 때문에 해당 규칙을 위반할 가능성이 있게된다. -
유연성이 떨어진다.
2. 스프링 컨테이너(싱글톤 컨테이너)
스프링 컨테이너는 앞서 설명한 싱글톤 패턴의 문제점들을 해결하고, 객체 인스턴스를 싱글톤으로 관리해준다.!
앞서 설명한 싱글톤 패턴의 문제점인 많은 코드, DIP, OCP, private 생성자등과 같은 것들을 모두 해결해주어 유연성이 높아지게 된다.
아래 예시를 통해 확인해보겠다.
@Configuration
public class appconfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(),discountPolicy());
}
@Bean
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
}@Test
@DisplayName("스프링 컨테이너와 싱글톤")
public void springContanier() {
ApplicationContext ac = new AnnotationConfigApplicationContext(appconfig.class);
MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);
System.out.println("memberservice1: "+ memberService1);
System.out.println("memberservice2: "+ memberService2);
Assertions.assertThat(memberService1).isSameAs(memberService2);
}@Bean 어노테이션을 통해 @Bean으로 선언한 객체들을 스프링 컨테이너가 싱글톤으로 관리할수 있게 한다.
테스트 결과 같은 객체 인스턴스가 나오게 된다.
스프링 컨테이너에서 빈으로 관리되는 객체 인스턴스를 반환해주기 때문이다.
참고로
스프링의 기본빈은 싱글톤 방식이지만 요청할때마다 새로운 객체를 반환하는 기능도 제공해준다.
결과적으로 싱글톤 패턴에서 문제가 되었던 private 생성자도 없게 되고
인터페이스에 의존하기 때문에 구현 클래스들을 쉽게 변경할수 있어 유연해지게 된다.
3. 싱글톤 방식의 주의점!
싱글톤 패턴이든 스프링 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하여 사용하기 때문에 싱글톤 객체는 무상태(stateless)로 설계해야된다.!!
무상태(stateless)로 설계해야한다는 말은
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할수 있으면 안된다.
- 읽기만 가능해야한다.
- 스프링 빈으로 관리하는 객체에 공유값이 있으며 안된다.
아래에 예시를 통해 간단히 살펴보겠다.
public interface StatefulService {
public void order(String name, int price);
public int getPrice();
}
public class StatefulServiceImpl implements 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
public void 상태유지싱글톤문제() throws Exception {
ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService 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원 출력
System.out.println("price = " + price);
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
static class TestConfig{
@Bean
public StatefulService statefulService(){
return new StatefulServiceImpl();
}
}
}위와 간단한 테스트 코드를 보게되면, StatfulSerive는 싱글톤 객체로 관리되게 된다.
싱글톤 객체를 A,B가 공유하여 사용하고 있는 상황에서 싱글톤 객체에 price라는 공유객체가 존재하게 되면 각 클라이언트가 값을 변경할수 있어 문제가 발생한다.!!
그러므로 무상태로 반드시 설계해야된다.!!
4. @Configuration과 싱글톤
4.1 싱글톤 문제 상황
앞서 appConfig 클래스를 살펴보게 되면
@Configuration
public class appconfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemberRepository memberRepository() {return new MemoryMemberRepository();}
@Bean
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(),discountPolicy());
}
@Bean
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
}스프링 컨테이너가 관리할수 있도록 Bean으로 등록하는 과정에서보면 아래와 같이 이상한점이 있다.
memverService메서드가 호출될때 ->memberReository()호출orderService메서드 호출 ->memberRepository()호출memberReository()도 따로 호출 -> 얘도스프링 빈으로 등록되어야 되니
이러한 식으로 똑같은 메서드가 3번 호출 되면서 MemberRepository 객체가 각각 생성되면서 싱글톤을 위반하는게 아닌가??!!
테스트 코드를 작성해서 살펴보게 되면
결과적으로 같은 객체를를 사용하는것을 볼수 있다.!! 즉, 싱글톤을 보장해주는것이다.
스프링의 @Configuration이 이를 해결해준다.
4.2 @Configuration과 바이트 코드
앞서 설명한 문제를 어떻게 해결하는지 살펴보겠다.
우리가 앞서 정의한 appconfig에 @Configuration이 붙은걸 확인할 수 있다.
그렇게 되면 스프링이 CGLIB라는 라이브러리를 사용하여 appconfig를 상속받은
다른 임의에 클래스를 만들고, 이 클래스를 스프링 빈으로 등록하게 된다.!!
(스프링 컨테이너가 해당 클래스를 스프링 빈으로 관리하게 되는것이다.)
즉, 아래의 그림같은것이다.
자세히 어떻게 해결하냐면,
스프링이 임의로 생성한 appconfig에 @Bean이 붙은 메서드를 오버라이드하여 재정의한다.
간략히 아래와 같이 오버라이딩 하게 된다.
위에 궁금즘에서 보다시피 memberReposiry 메서드를 3번 호출하는줄 알았지만,
스프링이 오버라이딩한 객체 내부 로직에서
해당 객체가 스프링 빈으로 등록되어있으면 등록된 객체를 반환하고 아니라면 정의한 로직이 호출하여 빈으로 등록하는 것이였다.
이를 통해 스프링 컨테이너가 싱글톤을 보장하는것이다.
기본을 좀더 탄탄히 하기 위해서 복습을 하고 내용을 정리해보았다.
나머지 기본지식들을 차근차근 복습하여 정리해봐야겠다.
