싱글톤 컨테이너, 웹애플리케이션과 싱글톤, 싱글톤 패턴, 싱글톤 방식의 주의점, @Configuration과 싱글톤, @Configuration과 바이트코드 조작의 마법

  출처 : 인프런 - 스프링 핵심원리 - 기본편(유료) / 김영한님  
  유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용  

https://inf.run/kCYMv

---

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

1) 순수 DI 컨테이너와 문제점

(1) 웹 애플리케이션

• 스프링은 기업용 온라인 서비스 기술을 지원하기 위해 탄생하였음
• 대부분의 스프링 애플리케이션은 웹 애플리케이션(웹이 아닌 애플리케이션도 개발할 수 있음)
• 웹 애플리케이션은 보통 여러 고객이 동시에 요청함

(2) 스프링 없는 순수한 DI 컨테이너 테스트

• test하위 경로에 singleton 패키지를 생성 후 테스트 코드 작성
• AppConfig()객체를 생성하여 memberService()를 호출해보면 각각의 참조값이 다름
• AppConfig클래스 내부에서 메서드를 호출할 때마다 new 연산자로 객체를 생성하고 있기 때문임

package hello.core.singleton;

public class SingletonTest {

    @Test
    @DisplayName("스프링이 없는 순수한 DI 컨테이너")
    void pureContainer() {
        AppConfig appConfig = new AppConfig();
        // 호출할 때마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();

        // 출력해보면 참조값이 다르다
        System.out.println("memberService = " + memberService1);
        System.out.println("memberService2 = " + memberService2);
        
        // memberService1 != memberService2
        Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    }
}

 

(3) 문제점

• 순수한 DI컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성
• 만약 고객 트래픽이 초당 100이 나오면 초당 100개의 객체가 생성되고 소멸되어 서버의 메모리 낭비가 심하게됨
• 해당 객체가 1개만 생성되고 공유하도록 설계 -> 싱글톤 패턴으로 해결

---

2. 싱글톤 패턴

1) 싱글톤

(1) 설명

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
• 객체 인스턴스를 2개이상 생성하지 못하도록 막음 ex) private 생성자를 이용해서 외부에서 new 키워드를 사용하지 못하게 막음
• 싱글톤 패턴을 적용하면 이미 만들어진 객체를 공유해서 효율적으로 사용 가능하지만 문제점이 존재함

(2) 싱글톤 구현

• 가장 단순하고 안전한 싱글톤 패턴 구현
• static 영역에 객체를 딱 1개만 생성하고
• 싱클톤 패턴을 구현하는 방법은 여러가지가 있음 (다른 방법은 검색을 통해 공부)

package hello.core.singleton;

// 가장 단순하고 안전한 싱글톤 패턴 구현 방법
public class SingletonService {

    // 1. static 영역에 객체를 딱 1개만 생성
    private static final SingletonService instance = new SingletonService();

    // 2. 객체가 필요하면 아래의 메서드를 통해서만 조회 하도록 허용(public)
    public static SingletonService getInstance() {
        return instance;
    }

    // 3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막음
    private SingletonService() {
    }

    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

 

(2) 싱글톤 패턴을 사용하는 테스트 코드

• new SingletonService(); 를 하면 컴파일 오류가 발생함
• 호출할 때 마다 같은 객체 인스턴스를 반환하는 것을 확인 가능

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
    SingletonService singletonService1 = SingletonService.getInstance();
    SingletonService singletonService2 = SingletonService.getInstance();

    // 같은 객체 인스턴스가 반환 됨
    System.out.println("singletonService1 = " + singletonService1);
    System.out.println("singletonService2 = " + singletonService2);

    assertThat(singletonService1).isSameAs(singletonService2);
}

 

(3) 싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감
• 의존 관계상 클라이언트가 구체 클래스에 의존하여 DIP를 위반함
• 클라이언트가 구체 클래스에 의존해서 OCP원칙을 위반할 가능성이 높음
• 유연하게 테스트 하기가 어려움
• 내부 속성을 변경하거나 초기화 하기 어려움
• private생성자로 자식 클래스를 만들기 어려워서 유연성이 떨어짐
• 안티패턴으로 불리기도함

---

3. 싱글톤 컨테이너

1) 스프링 싱글톤 컨테이너

• 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤(1개만 생성)으로 관리
• 이미 사용했던 스프링 빈이 싱글톤으로 관리되는 빈임

(1) 스프링 컨테이너를 사용하는 테스트 코드

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
    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);

    // memberService2 == memberService2
    assertThat(memberService1).isSameAs(memberService2);
}

 

(2) 스프링 컨테이너 적용 전/후

• 스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하지 않고 이미 만들어진 객체를 공유해서 효율적으로 재사용이 가능

좌)순수 DI컨테이너 / 우)스프링 DI 컨테이너

** 참고

• 스프링의 기본 빈 등록 방식은 싱글톤이며 거의 99% 사용함
• 그러나 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공 (빈 스코프 내용 참조)

---

4. 싱글톤 방식의 주의점

1) 싱글톤 주의사항

• 모든 싱글톤 방식(객체 인스턴스를 하나만 생성해서 공유하는 방식)은 여러 클라이언트가 하나의 같은 객체를 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful) 하게 설계하면 안됨
• 즉, 무상태(stateless)로 설계 해야함
  
• 특정 클라이언트에 의존적인 필드가 있거나 값을 변경할 수 있는 필드가 있으면 안됨
• 가급적 읽기만 가능 해야 함
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal등을 사용해야 함
• 스프링 빈의 필드에 공유값을 설정하면 정말 큰 장애가 발생할 수 있음 - 실무에서 자주 발생함

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

• 단순 설명을 위해 실제 Thread를 사용하지 않고 설명
• ThreadA가 사용자 A를, ThreadB가 사용자 B를 호출한다고 가정
• StatefulService의 price필드는 공유 되는 필드인데 특정 클라이언트가 값을 변경함
• 테스트코드를 작성하여 수행해보면 사용자 A의 주문금액이 10,000원 이여야 하는데 20,000원이라는 결과가 나옴 (실무에서 종종 발생 - 해결하기 어려운 큰 문제들이 터짐)
• 공유필드는 항상 조심! 스프링 빈을 무상태로 설계하여 문제 해결

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

 

class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        // Thread A : 사용자A가 10000원 주문
        statefulService1.order("userA", 10000);
        // Thread B : 사용자B가 20000원 주문
        statefulService2.order("userB", 20000);

        // Thread A : 사용자A 주문 금액 조회 = 20000원이 나와버림
        int price = statefulService1.getPrice();
        System.out.println("price = " + price);
        
        // 테스트 코드 - A의 금액이 20000원이 맞음
        assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

    static class TestConfig {

        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }
}

 

(3) 문제 해결

• StatefulService의 order()메서드를 수정
• 파라미터의 price를 인스턴스 변수에 저장하는 것이 아니라 그대로 반환하고 테스트코드에서 확인해보면 각 사용자가 주문한 금액이 반환됨

// 바로 매개변수의 가격을 넘겨버림
public int order(String name, int price) {
    return price;
}

-------------------------

// Thread A : 사용자A가 10000원 주문
int userAPrice = statefulService1.order("userA", 10000);
// Thread B : 사용자B가 20000원 주문
int userBPrice = statefulService2.order("userB", 20000);
// 각각 출력 
System.out.println("priceA = " + userAPrice);
System.out.println("priceB = " + userBPrice);

---

5. @Configuration과 싱글톤

1) AppConfig 클래스의 이상한 점

(1) AppConfig 구조

• memberService 빈을 만드는 코드는 memberRepository()를 호출
• orderService 빈을 만드는 코드는 memberRepository()를 호출
• memberRepository()가 호출 되면 new memoryMemberRepository()가 호출
• 결과적으로 각각 다른 2개의 memoryMemberRepository가 생성되면서 싱글톤이 깨지는 것 처럼 보임

@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();
    }
    ...
}

 

(2) 검증 용도의 코드 추가

• 테스트를 위해 MemberServicedImpl과 OrderServiceImpl에 MemberRepository를 조회할 수 있는 메서드를 추가

public class MemberServiceImpl implements MemberService {
    // ...기존 코드 유지
    // 테스트용
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }
}

public class OrderServiceImpl implements OrderService {
    // ...기존 코드 유지
    // 테스트용
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }
}

 

(3) 테스트 코드 

• 스프링 컨테이너에 AppConfig를 등록하고 getBean으로 빈을조회한 변수들로 memberRepository를 호출하여 같은 인스턴스인지 테스트를 해보면 모두 동일한 인스턴스로 테스트가 통과됨
• AppConfig의 코드는 분병히 new 연산자로 MemoryMemberRepository를 생성하도록 되어있는데 테스트에서는 모두 동일한 인스턴스로 확인되고 있음

public class ConfigurationSingletonTest {
    @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 -> memberRepository1 = " + memberRepository1);
        System.out.println("orderService -> memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

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

 

(4) AppConfig에 호출 로그 남김

• 빈으로 등록한 할인 정책을 제외한 모든 메서드에 출력 메서드를 작성하여 테스트 실행 시 로그로 몇번 호출되는지 확인할 수 있도록 코드를 작성
• 다시 위의 테스트를 실행해보면 출력결과의 로그는 1번씩만 실행됨
• 예상 : memberRepository 3번, orderService1번, memberService1번
• 출력 결과 : memberRepository, orderService, memberService 각 1번씩 출력 - 싱글톤이 유지 되고있음
• 즉, memberRepository 인스턴스는 모두 같은 인스턴스임을 알 수 있음

@Configuration
public class AppConfig {

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

    @Bean
    public OrderService orderService() {
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        System.out.println("call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }
    
    // 할인 정책 Bean은 동일
}

---

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

• 스프링 컨테이너는 싱글톤 레지스트리이므로 스프링 빈이 싱글톤이 되도록 보장 해주어야 함
• 그러나 스프링이 자바 코드를 마음대로 바꿀 수는 없기 때문에 싱글톤 유지를 위해서 바이트코드를 조작하는 라이브러리를 사용함

(1) 테스트코드 추가 및 분석

• AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록 됨
• 즉 AppConfig도 스프링빈으로 등록됨

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = ac.getBean(AppConfig.class);

    // bean의 클래스 타입을 출력
    System.out.println("bean = " + bean.getClass());
}

 

(2) AppConfig 스프링 빈을 조회에서 클래스 정보를 출력

• 출력 결과과 bean = class hello.core.AppConfig$$SpringCGLIB$$0 처럼 특이하게 나옴
• 순수한 클래스라면 bean = class hello.core.AppConfig 이렇게 출력이 되어야 함
• 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈에 등록함
• 그 임의의 클래스가 싱글톤이 되도록 보장해줌

좌) CGLIB가 사용되어 스프링 빈에 등록된 AppConfig / 우) AppConfig@CGLIB의 예상 코드(실제로는 매우 복잡함)

• AppConfing@CGLIB가 동작하는 방식이 @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 등록 된 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어지는 덕분에 싱글톤이 보장이 됨
• 참고로 AppConfig@CGLIB는 AppConfig의 자식타입이므로, AppConfig타입으로 조회 할 수 있음

(4) @Configuration을 적용하지 않고 @Bean만 적용 한다면?

• AppConfig에 작성해두었던 @Configuration을 주석처리

// @Configuration 삭제
public class AppConfig {
    // ... 코드 생략
}

 

(5) 기존과 동일한 테스트 실행

• AppConfig의 클래스타입을 출력한 로그를 보면 CGLIB 기술없이 순수한 AppConfig 클래스가 스프링 빈으로 등록된 것을 알 수있음
• AppConfig의 각 메서드에 등록했던 출력문 중 memberRepository가 3번이 출력되어 싱글톤이 깨진 것을 확인할 수 있음
• 1번은 @Bean에 의해 스프링 컨테이너에 등록하기 위해서 출력되고, 나머지 2번은 memberRepository()가 호출되서 발생된 것

// 최초 자바코드로 예상했던 결과가 출력 됨
call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository
call AppConfig.memberRepository

// 순수한 자바 클래스가 출력 됨
bean = class hello.core.AppConfig1

 

(6) 인스턴스가 같은지 테스트 결과

• 당연히 테스트 코드는 실패하고 로그를 보면 모두 다른 MemoryMemberRepository 인스턴스를 가지고 있음

memberService -> memberRepository1 
                  = hello.core.member.MemoryMemberRepository@35229f85
orderService -> memberRepository2
                  = hello.core.member.MemoryMemberRepository@6d3c5255
memberRepository = hello.core.member.MemoryMemberRepository@b1712f3

 

(7) 정리

• @Bean만 사용해도 스프링 빈으로 등록이 되지만 싱글톤을 보장하지 않음
• @Bean만 사용하면 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 (물론 @Autowired를 사용하여 자동으로 주입하는 방법이 있음)
• 고민할 것 없이 스프링 설정 정보는 항상 @Configuration을 사용해야함