싱글톤 이라는 디자인 패턴에 대해서 들어 봤을거다 (못들어봤다 사실 ㅎ)
싱글톤 패턴이 무엇이고, 왜 이 패턴을 적용해야만 할까?

우리가 만들었던 DI 컨테이너인 AppConfig는 요청이 있을 때마다 새로운 객체를 생성한다.
이 방법은 메모리 낭비가 심해지게 된다.

해결방안으로 해당 객체가 딱 하나만 생성되고, 그 인스턴스를 공유하도록 설계한다.
=> 이것이 싱글톤 패턴이다.

여러개의 객체를 만드는 것을 확인

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

  //memberService1 != memberService2
  assertThat(memberService1).isNotSameAs(memberService2);
  }
}

싱글톤 패턴

클래스의 인스턴스가 딱 하나만 생성되는 것을 보장하는 디자인 패턴이다.
직접 만드는 방법도 소개되어 있지만, 구현을 하려면 코드가 길어진다.
스프링을 이용하면 이런 고생 안해도 싱글톤 패턴을 맞춰준다.
(한번 만들어 보는것을 추천한다.)

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴을 직접 만드는 것의 단점을 해결한다
객체 인스턴스를 하나로 관리한다.
스프링 빈이 해당 역할을 한다.

public class SingletonTest {
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer() {
  ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
  
  MemberService memberService1 = ac.getBean(memberService.class);
  
  MemberService memberService2 = ac.getBean(memberService.class);

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

싱글톤 방식의 주의점

객체를 stateless 무상태 로 설계해야한다

잉? 이게 무슨 말일까?

a가 계산을 해서 5천원이 나왔다. => memberService.가격 = 5천원
b가 계산을 해서 8천원이 나왔다. => memberService.가격 = 8천원

a의 가격은 얼마인가 a.가격 => 8천원 ;;;;

price가 공유되는 값인데 특정 클라이언트가 가격을 변경해버렸다.
공유필드는 주의해서 사용하자. 아니 그냥 안건드리도록 하자
=> 방법 : 메서드에 return 값을 주고 사용할때는 변수에 담아서 사용해보자

@Configuration

스프링 컨테이너를 싱글톤 레지스트리로 등록해준다.
AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들어준다 => AppConfig@CGLIB
이 클래스에서는 바이트 코드를 조작하여 한번 생성된 객체는 그대로 사용하게끔 유도된다.