Spring gradle project 스프링 핵심 원리 기본편 | 웹 애플리케이션과 싱글톤 WebApplication and Singleton

---

본 포스팅은 인프런에 있는 인터넷 강좌인,

김영한 강사님의 스프링 핵심 원리 기본편을 공부하며,

개인적으로 공부하고, 정리하는 용도로 포스팅을 해보겠다.

 

Spring gradle project 환경설정 및 회원 가입 서비스 예제 만들기
Spring gradle project 주문/할인 도메인 설계

Spring gradle project 객체 지향 원리 적용

Spring gradle project AppConfig 리팩토링 OCP 위반 해결 및 중복 제거

Spring gradle project 좋은 객체 지향 설계 5가지 원칙 적용 및 스프링 전환

Spring gradle project 스프링 컨테이너와 스프링 빈

Spring gradle project BeanFactory, ApplicationContext 이해 및 차이

Spring gradle project XML 설정 사용, BeanDefinition, 스프링 빈 설정 메타 정보

웹 애플리케이션과 싱글톤

• 대부분의 스프링 애플리케이션은 기업용 온라인 서비스 기술 지원이 목적으로 웹 애플리케이션의 비중이 크다.
• 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.

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

package hello.core.singleton;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

public class SingletonTest {
    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer() {
        AppConfig appConfig = new AppConfig();
        //1. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();
        //2. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();
        //참조값이 다른 것을 확인

        System.out.println("memberService1 = " + memberService1); System.out.println("memberService2 = " + memberService2);
        //memberService1 != memberService2
        assertThat(memberService1).isNotSameAs(memberService2);
    }
}

• line 13 : AppConfig 클래스의 인스턴스를 생성
• line 15, 17 : memberService() 메서드를 두 번 호출하여 MemberService 객체를 두 번 생성한다. 이때 출력된 객체의 참조값은 각 호출마다 새로 생성되었음을 확인할 수 있다.
• 순수한 Java DI 컨테이너가 각각의 요청마다 새로운 객체를 생성되고 소멸되며 메모리 낭비가 심해, 특히 대규모 애플리케이션에서 비효율적일 수 있다.
• 이러한 문제를 해결하기 위해 싱글톤 패턴이 필요하며, 스프링 프레임워크는 기본적으로 이 패턴을 사용하여 빈(Bean)을 관리함으로써 객체의 중복 생성을 막기 위해, 메모리 사용을 최적화한다.

Singleton Pattern(싱글톤 패턴)

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이므로, 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.

public class SingletonService {

    //1. spring 로딩할 때, static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();

    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
        return instance;
    }

    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

• 이 서비스를 테스트 코드를 통해 실행해 보겠다.

import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

public class SingletonTest {
    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer() {
        AppConfig appConfig = new AppConfig();
        //1. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();
        //2. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();
        //참조값이 다른 것을 확인

        System.out.println("memberService1 = " + memberService1); System.out.println("memberService2 = " + memberService2);
        //memberService1 != memberService2
        assertThat(memberService1).isNotSameAs(memberService2);
    }

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

• 앞서 보였던 스프링 없는 순수한 DI 컨테이너를 이용한 코드와 비교 해봤다.
• line 27, 28 : SingletonService의 getInstance()를 반복적으로 호출하고 있지만, 호출할 때마다 같은 객체 인스턴스를 반환한다!
• 싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율 적으로 사용할 수 있다.

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다는 것은 곧, DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어지고, 안티패턴으로 불리기도 한다.

이런 싱글톤 패턴만으로 프로젝트를 구현하기에는 소비되는 리소스가 많다.

때문에 다음 포스팅에서는 이 싱글톤 패턴 문제를 해결할 수 있는,

싱글톤 컨테이너에 대해서 알아보도록 하겠다.

 

끝.