[스프링 핵심 원리] - 싱글톤 컨테이너

peeerr·2023년 1월 30일
Spring
0

Spring

목록 보기
4/10
post-thumbnail

이 글은 김영한님의 스프링 핵심 원리 - 기본편 강의를 수강하고 정리한 내용입니다.
강의 보러가기

📌 1. 웹 애플리케이션과 싱글톤

  • 대부분의 스프링 애플리케이션은 웹 애플리케이션이다.

  • 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.

dicontainer

  • 클라이언트 세 곳에서 동시에 memberService를 요청
    -> 우리가 직접 만들었던 DI 컨테이너(AppConfig)에서 MemberServiceImple 객체를 생성해서 반환한다.

    • @Bean을 사용하지 않는 순수한 DI 컨테이너
    • return new MemberServiceImpl(memberRepository());

  • 이런 방식이면 세 곳에서 요청을 받았으니 객체가 세 개가 생성된다.

    • 요청이 올 때마다 객체를 생성하는 것은 비효율적이다.

동시 요청을 받으면 요청마다 객체가 생성되는지 테스트

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

    // 1. 조회 : 호출할 때마다 객체를 생성
    MemberService memberService1 = appConfig.memberService();

    // 2. 조회 : 호출할 때마다 객체를 생성
    MemberService memberService2 = appConfig.memberService();

    // 참조값이 다른 것을 확인
    assertThat(memberService1).isNotSameAs(memberService2);
}

  • 호출을 할 때마다 객체를 새로 생성한다.

  • memberService에서 memberRepository 메서드까지 호출하므로 위 테스트에선 총 4개의 객체가 생성되는 것이다.


1) 문제점과 해결방안

  • 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다 -> 메모리 낭비가 심하다!

  • 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다! 이게 바로 싱글톤 패턴이다.


📌 1. 싱글톤 패턴

1) 싱글톤 패턴이란?

  • 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.

  • 객체를 2개 이상 생성하지 못하도록 막으면 된다.

    • 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("싱글톤 객체 로직 호출");
    }

}

  1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
    -> 서버(프로그램) 실행시 최초 한번만 메모리 할당하기 위해 static으로 선언
    -> static으로 선언하면 Garbage Collector의 영향을 받지 않기 때문에 프로그램 종료시까지 메모리가 할당된 채로 존재한다.

  2. 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회가 가능하다.
    -> 항상 같은 객체 인스턴스를 반환한다.

  3. 딱 1개의 객체 인스턴스만 존재해야 되므로, 생성자를 private으로 막아 new 키워드로 객체 인스턴스 생성하는 것을 막는다.
    -> SingletonService singletonService = new SingletonService(); 이런식으로 생성할 수 없게 된다.


싱글톤 테스트

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {

    // private 으로 생성자를 막아두었다. 컴파일 오류가 발생한다.
    // new SingletonService();

    //1. 조회 : 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService1 = SingletonService.getInstance();

    //2. 조회 : 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService2 = SingletonService.getInstance();

    // singletonService1 == singletonService2
    assertThat(singletonService1).isSameAs(singletonService2);
    
}
  • singletonService1 == singletonService2 임을 확인할 수 있다.

❓ isSameAs와 isEqualTo 차이 ❓
-> same은 자바의 == 연산, equal은 자바의 equals 메서드라고 생각하면 된다.


  • 이밖에도 싱글톤 패턴을 구현하는 방법은 여러가지가 있다.

    • 객체를 미리 생성해두지 않고 생성이 필요할 때 그제서야 생성하는 방법도 있다.

    • 위에서 적용한 객체를 미리 생성해두는 방법이 가장 단순하고 안전하다.


하지만 이러한 싱글톤 패턴은 수많은 문제점을 가지고 있다.

2) 싱글톤 패턴의 문제점

  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.

  • 의존관계상 클라이언트가 구체 클래스에 의존한다. => DIP 위반

    • 예를 들어 memberServiceImpl에 싱글톤 패턴을 적용한다면
      memberServiceImpl.getInstance() 을 호출해 객체를 사용하기 때문에 구체 클래스에 의존하는 것이다.

  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.

  • 테스트하기 어렵다.

  • 내부 속성을 변경하거나 초기화 하기 어렵다.

  • private 생성자로 자식 클래스를 만들기 어렵다.

  • 결론적으로 유연성이 떨어진다.

  • 안티패턴으로 불리기도 한다.

하지만 스프링 컨테이너는 싱글톤 패턴이 가진 문제점을 다 해결했다.


📌 2. 싱글톤 컨테이너

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

  • 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.

prev

  • 이전 글에서 사용한 그림이다. 빈 객체를 미리 하나씩 등록을 해서 관리해주는 것을 볼 수 있다.

1) 싱글톤 컨테이너 특징

  • 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.

    • 이전에 설명한 컨테이너 생성 과정을 자세히 보자.

  • 컨테이너는 객체를 하나만 생성해서 관리한다.

  • 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
    -> 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

  • 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

    • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.

    • DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.


테스트 예제

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    // 1. 조회 : 호출할 때 마다 같은 객체를 반환
    MemberService memberService1 = ac.getBean("memberService", MemberService.class);

    // 2. 조회 : 호출할 때 마다 같은 객체를 반환
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);

    // 참조값이 같은 것을 확인
    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);
    
    // memberService1 == memberService2
    assertThat(memberService1).isSameAs(memberService2);
}

출력결과

result

  • memberService1과 memberService2는 서로 같은 객체인 것을 알 수 있다.

2) 싱글톤 컨테이너 적용 후 요청 과정

after

  • 클라이언트에서 요청이 올 때마다 이미 만들어진 객체를 공유해 효율적으로 재사용할 수 있다.

스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아니다.

  • 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다.
  • 하지만 99%는 싱글톤 방식만 사용한다.
  • 자세한 내용은 뒤에 빈 스코프 챕터에서 설명

3) ❗(중요)❗ 싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 조심해야 될 것이 있다.

  • 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.

    • 무상태(stateless)로 설계해야 한다!

      • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
        -> 클라이언트가 값을 변경하게 두면 안된다.

      • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!

      • 가급적 읽기만 가능해야 한다.

      • 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

  • 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!!


이해가 안될 수 있으니 예시 코드를 보자.

1) 상태를 유지할 경우 발생하는 문제점 예시

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;
    }

}
@Test
void statefulServiceSingleton() {
    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 : 사용자A, 10000원 주문
    statefulService2.order("userB", 20000);

    // ThreadA : 사용자A 주문 금액 조회
    int price = statefulService1.getPrice();
    System.out.println("price = " + price);
}

출력 결과 즉, 사용자A 주문 금액은 얼마로 나올지 한번 생각해보자.

  • 사용자A가 10000원으로 설정한 후에 사용자B가 20000원으로 설정을 해버렸다.
    • service1이든 2든 서로 같은 객체이다. 그러므로 마지막으로 실행된 값이 price에 저장되므로 20000원이라고 출력된다.

  • 이해하기 쉬운 간단한 설명을 위해 실제 쓰레드는 사용하지 않았다.

  • StatefulService 의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.

  • 실무에서 이런 문제들이 많이 발생해 정말 해결하기 어려운 큰 문제들이 터진다고 한다..

  • 공유필드는 정말 조심해야 한다!
    스프링 빈은 항상 무상태(stateless)로 설계하자.

무상태 설계!

//private int price;  // 상태를 유지하는 필드

public int order(String name, int price) {
    System.out.println("name = " + name + ", price = " + price);
    return price;
}
  • 상태 유지 필드말고 파라미터를 이용해 무상태로 설계한다.

// ThreadA : 사용자A, 10000원 주문
int userAPrice = statefulService1.order("userA", 10000);
  • 반환값이 price가 되어 이걸 사용하면 문제를 해결할 수 있다.

📌 3. @Configuration과 싱글톤

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 FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

}

  • memberService 빈을 생성할 때

    • memberRepository() 메서드를 실행하면서 return new MemoryMemberRepository();까지 실행하게 된다.

  • orderService 빈 생성 과정에서도 마찬가지

    • memberRepository() 메서드를 실행하면서 return new MemoryMemberRepository();까지 실행하게 된다.

각각 다른 2개의 MemoryMemberRepository가 생성됐는데, 이러면 싱글톤이 깨지는 거 아닌가?


  • 각각의 memberRepository가 정말 다른 객체인 것인지 아닌지 테스트해보면 된다.

    • MemberServiceImpl , OrderServiceImpl에 다음과 같은 코드를 추가해준다.
// 테스트 용도
public MemberRepository getMemberRepository() {
    return memberRepository;
}
// 테스트 용도
public MemberRepository getMemberRepository() {
    return memberRepository;
}

이제 테스트 해보자

@Test
void configurationTest() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
    OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);

    MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);
    MemberRepository memberRepository1 = memberService.getMemberRepository();
    MemberRepository memberRepository2 = orderService.getMemberRepository();

    System.out.println("memberService -> memberRepository = " + memberRepository1);
    System.out.println("orderService -> memberRepository = " + memberRepository2);
    System.out.println("memberRepository = " + memberRepository);

    assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
    assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
}

출력결과
prres

  • memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용되는 것을 알 수 있다.
  • AppConfig의 코드를 보면 분명 각각 1번씩 new MemoryMemberRepository를 실행해서 다른 인스턴스가 생성되어야 하는데?
  • 혹시 두 번 호출이 안되는 것일까?

테스트를 통해 알아보자.

@Bean
public MemberService memberService() {
    System.out.println("call AppConfig.memberService");
    return new MemberServiceImpl(memberRepository());
}

@Bean
public MemberRepository memberRepository() {
    System.out.println("call AppConfig.memberRepository");
    return new MemoryMemberRepository();
}

@Bean
public OrderService orderService() {
    System.out.println("call AppConfig.orderService");
    return new OrderServiceImpl(memberRepository(), discountPolicy());
}
  • 호출될 경우, 메소드명을 출력하게끔 코드를 추가했다.

출력 예상

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository

호출 순서는 보장할 수 없으므로 출력되는 횟수만 신경써보자.
memberRepository 가 세 번 호출될 것으로 예상이 된다.

이제 위 테스트를 다시 돌려보면

prre

위와 같은 출력 결과를 얻는다.

  • memberRepository가 예상과 달리 한번만 호출되었다.

❓어떻게 된 것일까?


📌 4. @Configuration과 바이트코드 조작의 마법

1) 어떻게 싱글톤이 보장될까?

  • 스프링 컨테이너는 싱글톤 레지스트리다.
    -> 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.

  • 자바 코드를 보면 분명 memberRepository가 3번 호출되어야 한다.

  • 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다.
    -> 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

모든 비밀은 @Configuration 을 적용한 AppConfig 에 있다.

다음 코드를 보자

@Test
void configurationDeep() {
    // AppConfig 도 스프링 빈으로 등록된다.
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    AppConfig bean = ac.getBean(AppConfig.class);

    System.out.println("bean = " + bean.getClass());
}

  • AppConfig 빈을 꺼내와서 class 타입을 확인하는 코드이다.

  • 순수한 클래스라면 class hello.core.AppConfig 가 출력되어야 한다.

하지만 bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$9c1df86 가 출력되었다.

AppConfig까진 맞는데 뒤에 붙은 문자들은 뭐지?

  • 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다!

... 이해가 어려우니 그림을 보자
diffic

  • 내 AppConfig를 스프링 컨테이너에 등록하는 것이 아니라 임의로 만들어진 AppConfig@CGLIB라는 클래스가 등록된다.

  • 이 임의의 클래스가 바로 싱글톤이 보장되도록 해주는 것이다.

AppConfig@CGLIB는 아마 다음과 같이 바이트 코드를 조작해서 작성되어 있을 것이다.
(실제로는 CGLIB 내부 기술을 사용하는데 매우 복잡하다.)

@Bean
public MemberRepository memberRepository() {

    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있다면) {
        return 스프링 컨테이너에서 찾아서 반환;
    } else {  // 스프링 컨테이너에 없으면
        기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
        return 반환
    }
    
}

  • @Bean 이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고,
    스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

  • 덕분에 싱글톤이 보장되는 것이다.

AppConfig bean = ac.getBean(AppConfig.class);

  • 이렇게 AppConfig 타입으로 조회해도 AppConfig@CGLIB는 AppConfig의 자식 타입이기 때문에 문제없이 잘 동작한다.

2) @Configuration을 적용하지 않으면 어떻게 될까?

그럼 AppConfig에 @Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

  • AppConfig 빈을 조회해서 클래스 타입을 확인하면 아래와 같이 출력된다.
    bean = class hello.core.AppConfig

    • CGLIB 기술 없이 순수한 AppConfig로 스프링 빈에 등록된 것을 볼 수 있다.

  • MemberRepository가 세 번 호출된다.

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository
call AppConfig.memberRepository
  • 당연히 앞서 같은 인스턴스인지 테스트하는 것도 실패한다.

3) 정리

  • @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.

  • memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때, 싱글톤을 보장하지 않는다.

결론 : 그냥 스프링 설정 정보는 항상 @Configuration 을 사용하자

profile
peeerr
개발 공부
이전 포스트

[스프링 핵심 원리] - 스프링 컨테이너와 스프링 빈

다음 포스트

[스프링 핵심 원리] - 컴포넌트 스캔

0개의 댓글