[Spring] 김영한 기본편_ 섹션 6. 싱글톤컨테이너

<출처 인프런>

 

과연 스프링은 어떤 이점을 가지고 있을까? 실제로 웹사이트를 운영하게 되면 고객의 동시 요청을 처리하게 된다. 매번 고객의 요청을 처리할 때 마다 새로운 객체를 생성하게 되면 메모리 과부하가 오고 비효율적으로 운영하게 될 것이다. 스프링은 이런 경우 어노테이션을 이용하여 간단한 코드로 싱글톤 패턴을 유지시켜주며 개발자가 효율적이게 관리할 수 있도록 도와준다. 싱글톤 패턴이 무엇이며 스프링이 어떤 식으로 싱글톤을 관리해주는지 알아보자.

 

 

 

🧸 

---

🧸 구조파악 🧸

•  singleton
  ㄴ class : SingletonService, SingletonTest, StatefulService, StatefulServiceTest, ConfigurationSingletonTest 
• AppConfig

 

---

 

Q.  스프링을 사용하는 이유는?

A. 싱글톤이 보장되기 때문이다.

 

 

✔️  SingletonTest

 

► pureContainer

순수 자바코드로 생성자를 직접 호출한다.

 

AppConfig appConfig = new AppConfig();

MemberService memberService1 = appConfig.memberService();
MemberService memberService2 = appConfig.memberService();

스프링 컨테이너를 이용하지 않고 직접 AppConfig의 객체를 생성했다. appConfig에 있는 memberService 메서드를 이용하는데 타입은 MemberService이며 각 이름은 memberService1과 memberService2가 된다.

위의 코드는 싱글톤 패턴을 가진 클래스를 이용하지도, 스프링을 이용하지도 않았기 때문에 memberService1과 memberService2는 서로 다른 객체를 가질 것이다. 실제 프로그램에서는 다수 고객의 동시 요청이 발생한다. 고객이 요청할 때마다 AppConfig는 객체를 새로 생성해야한다. 이 많은 요청마다 새로운 객체를 만드는 것은 메모리 낭비를 유발한다.

 

 

▸  결과

각 값이 6a472554와 7ff2a664로 다른 것을 확인할 수 있다. 객체가 다르게 생성되었다는 것을 의미한다.

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

Assertions.assertThat(memberService1).isNotSameAs(memberService2);

 

assertThat(A).isNotSameAs(B)

: 대상 A와 대상 B의 주소값이 다른지 확인하는 메서드

 

Q. assertThat(A).isEqualTo(B)와 assertThat(A).isSameAs(B)와 차이점은 무엇인가?
A. isEqualTo는 대상의 내용을 비교하고 isSameAs는 대상의 주소값을 비교한다.

예시) isEqualTo

String A = "Hi";
String B = "Hi";

assertThat(A).isEqualTo(B);​

예시) isSameAs (==)

String A = "Hi";
String B = A;

assertThat(A).isSameAs(B);

 

 

 

 

---

 

 

 

✔️ SingletonService

싱글톤 디자인 패턴을 구현했다.

 

private static final SingletonService instance = new SingletonService();

 

private

: 외부에서 접근할 수 없게 한다.

 

static

:  instance 변수가 클래스 수준에서 관리되게 하며, 클래스가 메모리에 로드될 때 인스턴스가 생성되고 프로그램 종료될 때까지 유지된다.

 

final

: 인스턴스가 한 번 생성되면 변경할 수 없다.

 

 

Q. 싱글톤 패턴에 static은 왜 쓰는걸까? 

A.  static은 인스턴스(메모리 위에 올라간 객체)를 새로 생성하지 않아도 접근 가능하게 한다. 싱글톤 패턴은 단순히 하나의 인스턴스만 생성하는 것이 아니다. 하나의 인스터스를 생성 후 공유해 사용하도록 한다. 여기서 static은 하나의 인스턴스를 생성되도록 하며, 전역적으로 공유(사용)하도록 하게 해준다. private와 final의 역할은 외부에서 변경할 수 없도록 해준다.

 

 

 

- 싱글톤 패턴과 static의 관련 출처

싱글턴 패턴( Singleton Pattern ) 과 static - Java 디자인 패턴

 

 

Q. 객체와 인스턴스의 차이

A. 객체는 선언, 인스턴스는 실체화를 의미한다. 객체는 클래스의 타입으로 선언되었을 때, 인스턴스는 그 객체가 메모리 위에 올려졌을 때를 말한다. 그러니까 특별한 객체를 인스턴스라고 한다. (용어의 의미가 조금 다를 뿐, 객체와 인스턴스는 같다고 보면 되는 것 같다.)

Dog myDog = new Dog(); 
Dog anotherDog = new Dog();

위의 두 코드에서 myDog와 anotherDog는 Dog 클래스의 객체이자 인스턴스임을 나타낸다. 즉, 객체지만 인스턴스가 아닌 경우는 없다고 한다.

 

 

- 객체와 인스턴스의 차이점 출처

instance란?

 

 

 

•••그 다음 코드 •••

 

 

public static SingletonService getInstance() {
        return instance;
    }

SingletonService의 인스턴스를 새로 만들지 않고, getInstance( ) 메서드를 통해 인스턴스를 접근한다. 
그러니까 static으로 전역적으로 공유된 것을 사용하게 해주는 메서드가 getInstance( )인 듯 하다.

 

 

  private SingletonService() {

    }

 

생성자

: 인스턴스를 만들 때 호출되는 특별한 메서드

 

 

Q. 생성자가 정확하게 무엇인가?

A. 객체가 생성될때 자동으로 호출되는 특수 목적의 멤버함수(메소드)로 객체의 초기화를 위해 사용한다. 무조건 클래스당 하나가 있어야하며, 객체가 생성됐는데 그에 맞는 생성자가 없을 경우 컴파일러가 자동으로 기본생성자를 생성하거나 오류가 발생할 수 있다. 

	public Book() {	}                          // 기본생성자
	
	public Book(String title, int price) {    // 매개변수를 가진 생성자
		this.title = title;
		this.price = price;
	}

 

		Book b1 = new Book();                // 객체생성 - 기본생성자 호출됨
		Book b2 = new Book("국어책", 3000);   // 객체생성 - 매개변수를 가진 생성자 호출됨

 

 

 

- 생성자에 대한 설명 출처

[Java] 자바 - 생성자의 목적, 특징, 사용법 (Constructor)

 

 

Q. 그렇다면 위의 생성자는 기본 생성자인가? 왜 쓰는걸까?

A. 위의 생성자는 기본생성자와 차이가 있다. 일단 기본 생성자는 public을 기반으로 하는데, 위의 코드는 private로 개발자가 정의한 명시적 생성자(매개변수가 없는)다.  private를 사용한 이유는 싱글톤 패턴을 만들기 위해 외부에서 인스턴스를 만들 수 없도록 하기 위함이다.

 

 

••• 연결된 테스트 코드 확인하기 •••

 

 

✔️  SingletonTest

 

► singletonServiceTest

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

SingletonService의 코드를 생각해보면 인스턴스를 외부에서 만들지 못하도록 private 생성자를 만들었다. 그리고 static, final, private로 인스턴스 변경을 불가하게 만들었다. 그런데 전역적으로 공유를 하기 위해 getInstance 메서드를 만들었다.

getInstance( )를 통해 접근하여 singletonService1과 singletonService2의 인스턴스를 반환받는 것이다. 생성자를 직접 호출하지 않고 클래스 내에서 관리하는 유일한 인스턴스를 반환하는 정적 메서드를 사용하는 것이다.

 

 

 

► singleton 메모리 동작 살펴보기

# SingletonService
private static final SingletonService instance = new SingletonService();

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

 

클래스가 로딩되면 instance 변수가 메서드 영역에 적재된다. 그런데 이때 instance 실제 값이 메서드 영역에 있는 것이 아니라, instance라고 이름만 붙여진 껍데기만 메서드 영역에 있으며 실제 객체는 힙 영역에 저장되어있다. 메서드 영역에는 힙 영역에 있는 실제 객체값을 가리키는 주소값 위치가 존재한다.

singletonService1은 스택 영역에 생성되게 된다. 그러면 singletonService1은 메서드 영역의 instance가 가리키는 힙의 주소를 복사하여 저장한다. 그 후 singletonService2가 생성되어도 singletonService1와 같이 메서드 영역이 가리키고 있는 instance 힙의 주소를 복사하여 저장한다. 그래서 여러개를 생성해도 하나의 객체만 가리키게 되는 것이다.

만약 static을 붙이지 않게 되면 instance는 메서드에 적재되지 않고 힙에 적재된다. 이때 스택에는 객체 사용을 요구하는 변수가 들어오게 되면 힙 영역에 있는 instance는 계속해서 만들 수 있는 특성을 가지게 되기 때문에 new SingletonService( )를 호출하여 재귀적으로 instance의 새로운 객체를 반환한다.

 

 

 

► 결론

싱글톤 패턴을 사용하면 DIP,OCP를 위반할 수 있다. 더구나 private 사용으로 인해 유연성도 떨어진다.

그렇기에 스프링 컨테이너를 사용하여 인스턴스를 싱글톤으로 유지하는 방식을 사용할 것이다.

 

 

 

 

---

 

 

 

 

✔️ SingletonTest

 

► springContainer

// 스프링을 사용하기 위해 아래 코드 정의
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);

AppConfig에 정의되어있는 memberService라는 이름을 가진 빈을 MemberService 타입으로 반환한다. 이때 스프링 컨테이너의 특성에 의해 같은 빈 인스턴스를 할당한다.

 

 

같은 결과값이 나온 것을 확인할 수 있다.

 

 

 

 

---

 

 

 

✔️  StatefulService

객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 무상태로 설계해야한다.

 

 

► 상태를 유지하도록 설계할 경우 발생하는 문제점

# StatefulService
private int price; 

public void order(String name, int price) { 
	...
	this.price = price; 
}

# StatefulServiceTest

statefulService1.order("userA", 20000);
statefulService2.order("userB", 10000);

int price = statefulService1.getPrice();
System.out.println("price = " + price);

 

처음에 order에 20000이 들어왔다. 그러면 this를 통해 들어온 값은 필드에 있는 price로 들어가면서 값이 공유된다. 그리고나서 userB가 10000을 주문했다. 그러면 다시 필드는 10000의 값을 가지게 된다. 값이 즉각적으로 돌려지는 방식이 아닌 이렇게 상태를 유지하는 방식으로 설계했기 때문에 최종적으로 price의 값은 10000이 되고 그 후에 statefulService1의 price를 출력하니 마지막 상태였던 10000이 나오게 된다.

 

 

 

► 무상태로 설계하기

public int order(String name, int price) {
        ...
        return price;
    }

order 메서드가 가격을 바로 반환하도록 설계하면 된다. 이렇게하면 상태를 유지하지 않고, 각 요청이 독립적으로 처리될 수 있다.

 

 

 

---

 

 

 

 

✔️  StatefulServiceTest

 

► TestConfig

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

@Bean을 써서 간단한 설정 클래스를 만들었다.

 

 

•••그 다음 코드 •••

 

	StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

statefulService1과 statefulService2의 인스턴스를 요구한다. 그러면 TestConfig에 있는 StatefulService로 가서 인스턴스를 생성하고 반환한다.

 

 

•••그 다음 코드 •••

 

	int userAprice = statefulService1.order("A", 2000);
        int userBprice = statefulService2.order("B", 1000);

StatefulService의 order 메서드를 호출한다. 순서대로 내부상태필드 price에 각 값을 저장하고 이 값을 반환한다.

 

 

 

정상적으로 반환한다

 

 

 

 

---

 

 

 

✔️  자바 코드의 싱글톤 유지법

 

► AppConfig

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

코드를 살펴보면 memberService에서 memberRepository가 호출되고 memberRepository에 있는 MemoryMemberRepository가 호출된다. memberRepository에서 MemoryMemberRepository가 호출된다. orderService에서 memberRepository가 호출되고 memberRepositorysms MemoryMemberRepository를 호출한다. 그렇게 총 3번의 MemoryMemberRepository가 호출되는 것으로 보이면서 싱글톤이 깨져보인다. 과연 진짜로 싱글톤이 깨지는지 확인해보자.

 

 

 

► MemberServiceImpl

    public MemberRepository getMemberRepository() {
    	return memberRepository;
    }

memberRepository가 private final로 정의되어있기에 외부 테스트 클래스에서 memberRepository를 사용하기 위해getMemberRepository를 이용하여 객체를 가져온다. 이때 memberRepository는 인터페이스로 MemoryMemberRepository에 상속되어있다.

 

 

 

► ConfigurationSingletonTest

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

memberService와 orderService는 getMemberRepository를 통해 memberRepository의 객체를 출력한다. 출력 결과 memberRepository는 같은 인스턴스가 공유되어 사용하고 있음을 알 수 있다. 

 

 

► 이유에 대하여

@Configuration
public class AppConfig {

@Configuration이 붙게되면 AppConfig는 내가 만든 클래스가 아닌 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록한 것을 알 수 있다. 즉 AppConfig에 AppConfig@CGLIB가 오버라이딩 되어서 실제 실행은 AppConfig@CGLIB가 된 것이다.

만약 @Configuration을 붙이지 않으면 @Bean이 붙은 메서드가 호출될 때마다 새로운 인스턴스를 생성하게 될 것이다.

---

 

🌷

 

이렇게 싱글톤을 어떻게 만드는지, 스프링이 싱글톤을 어떤 방식으로 보장해는지에 대해 알아보았다.

스프링 컨테이너 자체적으로 빈을 한 번만 생성하고 재사용하는 것도 알게되었지만,

@Configuration을 통해 자바 코드도 같은 방식으로 동작하게 한다는 걸 알 수 있었다.