[Spring] 스프링을 이용해 회원-주문 서비스 개발, 스프링 컨테이너와 싱글톤

- 김영한 님의 '스프링 핵심원리 - 기본편'을 보고 정리한 글입니다 😊

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

---

- 지난 포스팅과 이어집니다 :D

[Spring] 순수 자바로 회원-주문 서비스 개발하기

- 지난 포스팅에서, 순수 자바만을 이용해 회원 - 주문, 그리고 할인 서비스를 개발하였다.

- SRP, OCP, DIP를 만족하도록 설계하였으나, 사용자가 직접 Config를 관리해야 하는 등 번거로운 부분들이 생겼다.

- 그러나, 스프링에서는 이를 다 프레임워크 단위로 넘기기 때문에, 사용자가 의존관계를 비교적 덜 신경써도 된다!

 

 

| 제어의 역전 - IoC (Inversion of Control)

- 기존에는 프로그램의 제어 흐름을 AppConfig가 가지고 있었다. 각 클라이언트는 어떤 구현 객체가 들어오는지 모른다!

- 이런 식으로, 프로그램의 제어 흐름을 외부에서 관리하는 것이 제어의 역전이다.

    - 참고로, 프레임워크가 내가 작성한 코드를 제어하고 실행한다면 라이브러리가 아닌 '프레임워크'라고 한다.

    - 그런 의미로 스프링 역시 일종의 프레임워크이다. 

 

 

| 의존관계 주입 - DI (Dependency Injection)

- 정적인 클래스 의존관계 : 실행하지 않아도 의존관계 분석 가능.

    - 단순히 OrderServiceImpl이 MemberRepository와 DiscountPolicy를 의존하고 있음.

- 동적인 객체 인스턴스 의존관계 : 실행 시점에 구현 객체를 외부에서 생성하고, 클라이언트에 전달해서 의존관계 연결

    - 실제로 DiscountPolicy에 Fix가 들어갈지, Rate가 들어갈지.

    - 객체 인스턴스를 생성하고, 각 참조값을 전달해서 연결한다.

- 의존관계 주입을 사용하면, 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

 

🚩 AppConfig처럼 객체를 생성하고 관리하면서, 의존관계를 연결해주는 게 IoC Container / DI Container라고 한다.

---

- 이제, 우리가 짰던 코드에 스프링을 적용해보자.

[AppConfig.java]

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

    @Bean
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

- @Configuration, @Bean이라는 어노테이션이 붙은 걸 확인할 수 있다.

- 스프링 컨테이너에 @Bean이 붙은 메서드를 스프링 빈으로 등록한다!

 

- 이렇게 스프링 빈으로 등록된 친구를 꺼내기 위해서는, ApplicationContext를 사용한다.

public class MemberApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext =
                new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService =
                applicationContext.getBean("memberService", MemberService.class);
    }
}

- 여기서 ApplicationContext가 바로 스프링 컨테이너이며, 이때 구성 정보로 @Configuration이 붙은 AppConfig를 사용한다.

- ✔ 이후, @Bean이 붙은 메서드를 모두 호출하여 반환된 객체를 스프링 컨테이너에 등록하며, 각각은 스프링 빈이 된다.

- @Bean이 붙은 메서드 명이 곧 빈의 이름이 된다. ac.getBean(bean_name)으로 찾아올 수 있다!

 

- 스프링 컨테이너로 관리하면 뭐가 좋을까?

 

---

| 스프링 컨테이너 (ApplicationContext)

- ApplicationContext는 인터페이스로 되어 있으며, XML, 혹은 애노테이션 기반의 자바 설정 클래스로 만들 수 있다.

   - 요즘은 XML보다는 대부분 어노테이션을 통해서 만드는 것 같다.

 

✔ 스프링 컨테이너 생성

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

- 스프링 컨테이너 생성 시, 구성 정보를 지정해주어야 한다. 

- 스프링 컨테이너 내부의 빈 저장소에는 빈 이름과 실제 빈 객체 주소를 가지고 있다.

 

✔ 스프링 빈 등록

- 설정 정보 클래스에 등록된 @Bean 메서드 정보를 통해 스프링 빈을 등록한다.

- 빈 이름은 메서드 이름 or @Bean(name="") 수동 지정 가능!

🚩 빈 이름은 항상 다른 이름을 부여해야 한다. 아니면 실행할 때 에러난다...! (그래서 웬만하면 수동 지정 안 하는 게 나을 듯)

 

✔ 스프링 빈 의존관계 설정 - 준비

- 각 빈에 해당하는 객체를 생성한다.

🎈준비 단계와 완료 단계를 나누어두었다. 이유는 추후 포스팅으로 다루겠다.

 

✔ 스프링 빈 의존관계 설정 - 완료

- 설정 정보를 참고해서 의존관계를 주입한다.

 

 

- 실제로, 코드에서 우리가 등록한 빈을 확인해보자.

[ApplicationContextInfoTest.java]

public class ApplicationContextInfoTest {
    AnnotationConfigApplicationContext ac
            = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    public void findAllBean() throws Exception {
        // given
        String[] names = ac.getBeanDefinitionNames();
        List<String> registBean = new ArrayList<>();

        System.out.println("get All Bean");
        for(String name: names) {
            Object bean = ac.getBean(name);
            BeanDefinition definition = ac.getBeanDefinition(name);
            System.out.println("name = " + name + " bean = " + bean);
            if(definition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                registBean.add(name);
            }
        }
        System.out.println("직접 등록한 애플리케이션 빈");
        for(String name : registBean) {
            System.out.println("name = " + name);
        }
    }
}

✔ 실행 결과

<get All Bean>
name = org.springframework.context.annotation.internalConfigurationAnnotationProcessor
bean = org.springframework.context.annotation.ConfigurationClassPostProcessor@27a0a5a2

name = org.springframework.context.annotation.internalAutowiredAnnotationProcessor
bean = org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor@7692cd34

name = org.springframework.context.annotation.internalCommonAnnotationProcessor
bean = org.springframework.context.annotation.CommonAnnotationBeanPostProcessor@33aa93c

name = org.springframework.context.event.internalEventListenerProcessor
bean = org.springframework.context.event.EventListenerMethodProcessor@32c0915e

name = org.springframework.context.event.internalEventListenerFactory
bean = org.springframework.context.event.DefaultEventListenerFactory@106faf11

name = appConfig
bean = study.springstudy.config.AppConfig$$EnhancerBySpringCGLIB$$33662889@70f43b45

name = memberService
bean = study.springstudy.domain.service.MemberServiceImpl@26d10f2e

name = orderService
bean = study.springstudy.domain.service.OrderServiceImpl@10ad20cb

name = memberRepository
bean = study.springstudy.domain.repository.MemoryMemberRepository@7dd712e8

name = discountPolicy
bean = study.springstudy.domain.service.discount.FixDiscountPolicy@2c282004

<직접 등록한 애플리케이션 빈>
name = appConfig
name = memberService
name = orderServicename = memberRepository
name = discountPolicy

 

✔ 스프링 내부에서 기본으로 사용하는 빈

- ConfigurationClassPostProcessor

: @Configuration이 등록된 빈 객체에서 @Bean이 붙어 있는 빈 객체를 가져와 스프링 컨테이너에 등록한다.

 

- AutowiredAnnotationBeanPostProcessor

: @Autowired에 대한 의존 주입 처리를 진행한다. @Autowired가 적용된 필드, 생성자, 메서드에 알맞은 의존 객체를 주입한다.

 

- CommonAnnotationBeanPostProcessor

: JSR-250 (@PostConstruct 등)에 대한 라이프사이클 처리를 진행한다.

 

- EventListenerMethodProcessor

: EventListener 메서드를 개별 ApplicationListener 인스턴스로 등록한다. (불확실)

 

- DefaultEventListenerFactory

: @EventListener를 처리한다. (불확실)

 

 

✔ 직접 등록한 빈

- AppConfig

- memberService -> memberServiceImpl

- orderService -> orderServiceImpl

- memberRepository -> MemoryMemberRepository

- discountPolicy -> FixDiscountPolicy

---

| 스프링 빈 조회하기

- ac.getBean(bean_name, type)

- ac.getBean(type)

: 이름+타입, 혹은 타입으로 조회할 수 있다.

@Test
public void findBeanTest() throws Exception {
        // 빈 이름으로 조회
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        assertThat(memberService1).isInstanceOf(MemberServiceImpl.class);

        // 타입으로 조회
        MemberService memberService2 = ac.getBean(MemberService.class);
        assertThat(memberService2).isInstanceOf(MemberServiceImpl.class);

        // 구체 타입 조회 - 유연성 떨어짐
        MemberServiceImpl memberService3 = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService3).isInstanceOf(MemberServiceImpl.class);
        }

- 만약, 동일한 타입을 가지고 있는 빈이 여러 개가 존재한다면 어떻게 할까?

    - 이때, 타입 조회를 사용하면 오류가 발생한다. (NoUniqueBeanDefinitionException)

- 그렇기 때문에 둘 이상일 경우는 빈 이름 조회를 사용하는 것이 좋다. (ac.getBean(bean_name, type))

 

- 동일한 타입을 가지고 있는 빈을 조회하려면 ac.getBeansOfType()을 사용한다.

public class ApplicationContextInfoTest {
    AnnotationConfigApplicationContext ac2 = new
            AnnotationConfigApplicationContext(SameBeanConfig.class);

    @Test
    public void findAllBeanByType() throws Exception {
        Map<String, MemberRepository> beansOfType =
                ac2.getBeansOfType(MemberRepository.class);
        System.out.println("beansOfType = " + beansOfType);
        for(String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
        assertThat(beansOfType.size()).isEqualTo(2);
    }

    @Configuration
    static class SameBeanConfig {
        @Bean
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }
        @Bean
        public MemberRepository memberRepository2() {
            return new MemoryMemberRepository();
        }
    }
}

✔ 실행 결과

beansOfType = {memberRepository1=study.springstudy.domain.repository.MemoryMemberRepository@78e16155, memberRepository2=study.springstudy.domain.repository.MemoryMemberRepository@54a3ab8f}
key = memberRepository1 value = study.springstudy.domain.repository.MemoryMemberRepository@78e16155
key = memberRepository2 value = study.springstudy.domain.repository.MemoryMemberRepository@54a3ab8f

- 임시로 Config 클래스를 선언해줘서 동일한 타입을 가진 빈을 생성하였다.

- 위처럼 MemberRepository 타입을 가진 빈이 잘 조회되는 것을 확인할 수 있다. (Map 형태로, 빈 이름과 구현체가 나온다)

 

- 또한, 부모 타입으로 조회 시 자식이 둘 이상이라면 빈 이름 조회를 사용하면 되며,

여러 개를 조회하고 싶다면 위처럼 getBeansOfType()을 사용하면 된다.

---

| BeanFactory vs ApplicationContext

✔ BeanFactory

: 스프링 컨테이너의 최상위 인터페이스. getBean()을 제공한다.

 

✔ ApplicationContext

: BeanFactory를 상속받는다. 빈 조회 외에도 수많은 기능을 제공한다.

- MessageSource : 국제화 기능 (message.properties)

- EnvironmentCapable : profile, property 관리 기능.

    - profile : 특정한 실행 환경에서 사용하는 빈 그룹 나누기 (@Profile)

    - property : 애플리케이션 구동 시 필요한 정보를 key-value 형태로 정의할 수 있으며, 우선순위가 높은 순으로 가져온다.

- ApplicationEventPublisher : 이벤트 프로그래밍에 필요한 기능 제공 (@EventListener)

- ResourceLoader : 파일, 클래스패스, 외부 등에서 리소스를 가져올 수 있다. (ResourceLoader.getResource)

 

---

| BeanDefinition

- 앞서 잠깐 언급하였지만, 스프링에서는 설정 정보를 xml, 혹은 어노테이션을 통해서 등록할 수 있다.

- 스프링에서는 어떻게 다양한 방법으로 설정 정보를 등록할 수 있도록 하였을까?

🚩 바로, BeanDefinition을 통한 추상화 덕분이다.

- XML이든, 자바 코드든 BeanDefinition을 만들기만 한다면 스프링 컨테이너는 오직 BeanDefinition을 의존한다.

    - BeanDefinition을 빈 설정 정보라고 하며, @Bean, <bean>당 하나씩 메타 정보가 생성된다.

    - 스프링 컨테이너는 이러한 메타 정보를 바탕으로 스프링 빈을 생성한다.

 

✔ 구체적인 생성 방식

- AnnotationConfigApplicationContext는 AnnotatedBeanDefinitionReader를 통해서 자바 코드 기반 설정 정보(@Configuration)를 읽어 생성.

- GenericXmlApplicationContext는 XmlBeanDefinitionReader를 통해서 XML을 읽어 생성.

- 즉, 이런 식으로 Reader를 통해 BeanDefinition을 만들어주기만 하면 된다.

 

✔ BeanDefinition엔 어떤 정보들이 있을까?

- BeanClassName : 생성할 빈의 클래스 네임. (어노테이션 기반에서는 null)

- factoryBeanName: 팩토리 역할의 빈 네임(appConfig)

- factoryMethodName: 빈을 생성할 메서드 (memberService)

- Scope: 기본적으로 싱글톤이다.⭐

- lazyInit: 컨테이너 생성 시 빈이 생성되는 것이 아닌, 실제 사용 시점에 빈을 사용하도록 지연 처리 여부

- InitMethodName: 빈 생성 후 의존관계 적용했을 때 호출되는 초기화 메서드 네임

- DestroyMethodName: 빈 소멸 후 제거 직전에 호출되는 메서드 네임

- Constructor arguments, Properties: 의존관계 주입에서 사용하는 설정. (어노테이션 기반에서는 null)

---

| Singleton Pattern

- 스프링이 제공하는 DI 컨테이너의 경우, 싱글톤을 보장한다.

 

✔ 싱글톤이란?

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

 

✔ 싱글톤을 실현할 수 있는 방법

public class SingletonService {
    private static final SingletonService service = new SingletonService();

    public static SingletonService getService() {
        return service;
    }

    private SingletonService() {
    }
}

- 생성자를 private으로 두었기 때문에, SingletonService 객체를 외부에서 new로 생성할 수 없다.

- static 영역에 선언하여 객체를 딱 1개만 생성해둔다. final로 선언한 것은 값이 변경되지 않으니까.

(🚩 static 키워드를 붙이면 내부적으로 메모리 할당을 한 번만 수행한다 = 같은 곳의 메모리 주소만 바라본다.)

- service를 가져오기 위해서 getService() 메서드만 public으로 열어두었다.

앞으로 SingletonService의 service를 가져오기 위해서는 getService() 메서드로만 접근이 가능하다.

 

SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();

- 여기서 singletonService1, 2는 같은 메모리 주소를 바라보게 된다. 같은 인스턴스를 반환하니까!

 

✔ 그러나, 싱글톤 패턴은...

- 코드 구현이 필요하기 때문에 로직이 지저분해진다.

- DIP를 위반한다. 구체 클래스에 의존하기 때문에! -> OCP를 위반할 수도 있다.

- 테스트하기가 어려우며, 내부 속성 변경이 어렵다. -> 유연성이 떨어진다.

 

---

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

- 스프링 컨테이너가 곧 싱글톤 컨테이너가 되며, 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

- 덕분에 개발자가 직접 코드를 삽입할 필요도 없으며, DIP, OCP로부터 자유롭게 사용이 가능하다!

@Test
void springContainer() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberService memberService1 = ac.getBean("memberService",
    MemberService.class);
    MemberService memberService2 = ac.getBean("memberService",
    MemberService.class);

    // memberService1 = study.springstudy.domain.service.MemberServiceImpl@6a175569
    System.out.println("memberService1 = " + memberService1);
    // memberService2 = study.springstudy.domain.service.MemberServiceImpl@6a175569
    System.out.println("memberService2 = " + memberService2);

    assertThat(memberService1).isSameAs(memberService2);
}

- 확인해보면, 요청이 올 때마다 객체를 생성하지 않고 이미 만들어진 객체를 다시 반환해준다!

 

✔ 싱글톤 주의사항

- 하나의 객체 인스턴스를 공유하기 때문에, stateless하게 설계해야 한다.

- 가급적 읽기만 가능해야 한다. (값을 변경하게 되면 위험)

- 스프링 빈의 필드에 공유값은 절대절대 설정하지 말 것.

 

---

| @Configuration과 Singleton

- 스프링은 바이트코드를 조작하는 라이브러리를 사용하여 싱글톤을 보장한다.

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = ac.getBean(AppConfig.class);
    // bean = class study.springstudy.config.AppConfig$$EnhancerBySpringCGLIB$$30df2dad
    System.out.println("bean = " + bean.getClass());
}

@Configuration을 사용하면 AppConfig bean을 확인해 보면 프록시 객체인 걸 볼 수 있다! (CGLIB)

: 참고로, AppConfig@CGLIB는 AppConfig를 상속받아서 구현한다. (그래서 AppConfig.class로 getBean 조회가 가능한 것. 부모 타입이니까)

즉, 스프링 빈을 등록할 때 내부적으로 실제 AppConfig 대신 프록시 객체를 생성하여 등록하는 것이다.

 

내부적으로 @Bean이 붙은 메서드마다 이미 스프링 컨테이너에 등록되어 있다면, 컨테이너에서 찾아서 반환해주고,

없으면 기존의 로직을 호출하여 객체를 생성한 다음 스프링 컨테이너에 등록시키는 과정을 통해 동적으로 스프링 빈을 등록 및 반환한다.

 

만약, AppConfig에 @Configuration을 붙이지 않고 단순히 @Bean만 붙이면 CGLIB을 사용하지 않으며, 싱글톤 역시 보장하지 않는다.

🚩 즉, 실질적인 싱글톤 보장은 @Configuration을 통해 이루어지며, @Bean은 스프링 빈 등록 역할만 한다.

 

우리는 지금까지 @Configuration, @Bean을 통해 빈을 등록하였는데, 이를 더 자동화시킬 수는 없을까?

-> 컴포넌트 스캔을 이용하자! 이는 다음 포스팅에서 다루겠다.