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

<출처 인프런>

 

원래대로라면 섹션 4-2를 작성해야하지만... 4-1을 정리하고 velog에 있던 글들 Tistory로 다시 옮기면서 강의 내용이 제대로 기억나지 않게 되었다. 그래도 keep going~ 4-2는 8월 중순에 다시 들으면서 정리하기로 하고 섹션 5 강의 부터 정리해볼까 한다. 히히. 취업이 요새 잘 안되는 것 같아 약간의 두려움이 있지만 그래도 모두들 화이팅!

 

 

 

🧸 

---

🧸 구조파악 레츠꼬우- 🧸

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

 

---

 

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

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

 

 

✔️  SingletonTest

 

► pureContainer

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

 

MemberService memberService1 = appConfig.memberService();

MemberService memberService2 = appConfig.memberService();

 

AppConfig를 보면 MemberService타입의 bean 이름이 memberService 라는 것을 만든걸 확인할 수 있다.
appConfig.memberService는 MemberService 타입의 객체를 생성하고 반복한다는 뜻이다.
memberService1은 memberService를 가리키는 객체가 된다. (우리가 알기쉽게 이름만 대여해주는 느낌인 것 같다...(?))

결론적으로 memberService1을 통해 MemberServiced 객체에 접근하고 사용한다. 일단 이렇게 이해하긴함🧐

 

현재 만든 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은 왜 쓰는걸까? 

전에 자바완전정복에서 static에 대한 개념을 찾아봤던 것이 기억난다. 그때는 main 메서드에 들어가 있던 것 같았는데, 하여튼 기억을 e되짚어보자면 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의 인스턴스를 반환받는 것이다. 생성자를 직접 호출하지 않고 클래스 내에서 관리하는 유일한 인스턴스를 반환하는 정적 메서드를 사용하는 것이다.

 

 

 

---

 

 

✔️ SingletonTest

 

► springContainer

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

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

 

 

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

 

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

 

 

 

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

 

 

 

 

---

 

 

 

✔️  StatefulService

스프링 컨테이너는 무상태로 설계해야한다.

 

 

 

👁️‍🗨️ 문제점

 

스프링컨테이너 혹은 싱글톤 패턴은 하나의 인스턴스를 가져와 공유하게 된다.

만일 상태를 가지는 필드가 있다면, 처리에 문제가 생기게 된다.

 

private int price; 

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

 

첫번째 주문자가 2만원을 주문했는데 그것을 처리하는 동안 두번째 주문이 10만원 들어오게 되면,
첫번째 주문자의 주문가격이 10만원으로 변경될 수 있다.

 

 

 

 

💫  해결해보자

 

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

 

1. 무상태로 만들기 위해 원래 있던 this.price = price;를 지워준다.
2. 리턴값을 들어왔던 가격으로 나가도록 return price;로 수정한다.

 

 

 

---

 

 

 

 

✔️  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에 붙어있는 @Configuration과 @Bean을 통해 각 인스턴스의 싱글톤을 보장해준다.

만일 @Configuration이 없다면 AppConfig의 memberRepository는 다른 인스턴스를 가져 호출될 것이다.

 

그리고 주의해야할 것은 무상(stateless)를 유지하는 것이다.