🔸 스프링은 애초에 기업용 온라인 서비스를 위해서 탄생했다.
🔸 대부분의 스프링 애플리케이션은 웹 애플리케이션이다.
🔸 웹 애플리케이션은 클라이언트가 동시에 요청한다.
🔸 고객의 요청이 올 때마다 항상 새로운 객체를 만들어서 응답한다.
🔸 이를 해결하기 위한 방법으로 해당 객체를 1개만 생성하고 공유하도록 설계 ➡️ 싱글톤 패턴
🔸 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
🔸 private 생성자를 사용하여 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.싱글톤 생성 public class SingletonService{ private static final SingletonService instance = new SingletonService(); public static SingletonService getInstance(){ return instance; } private SingletonService(){ } } 객체 사용 SingletonService singletonService1 = SingletonService.getInstance();
🔸 static 으로 하는 이유는 클래스 레벨로 올라가기 때문에 하나만 존재하게 됨.
assertThat().isSameAs() : == 인스턴스의 참조값을 비교
assertThat().isequalTo() : .equals() 객체의 값(문자열의 내용, 데이터)이 같은지를 비교
- 싱글톤 패턴 구현 코드가 많이 들어간다.
- 의존관계(클라이언트가 구현클래스에 의존해야 한다.) -> DIP위반
- 클라이언트가 구현클래스에 의존해서 OCP원칙 위반 가능성이 높다.
- 테스트하기가 어렵다.
- 내부속성 변경이 어렵다.
- private생성자를 사용하여 유연성이 떨어지고 자식클래스를 만들기 어렵다.
🔸 스프링컨테이너(ApplicationContext)를 사용하면 알아서 싱글톤으로 관리해준다.
➡️ 싱글톤 패턴의 문제점은 해결하고 객체 인스턴스들을 싱글톤으로 관리한다.
🔸 싱글톤 객체를 생성하고 관리하는 기능 : 싱글톤 레지스트리라고 한다.ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); MemberService memberService1 = ac.getBean("memberService", MemberService.class);
- 싱글톤 패턴 구현을 위한 지저분한 코드가 사라진다.
- DIP, OCP위반 및 테스트에서 자유로우며 private생성자로부터 자유로워진다.
🔸 하나의 객체를 공유해서 사용하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다.
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. (읽기만 가능하도록)
- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
🔸 아니면 큰 장애가 발생할 수 있다.
🔸 스프링은 클래스의 바이트 코드를 조작하는 라이브러리를 사용하여 싱글톤을 보장한다.
ApplicationContext ac = new AnnotationCofigApplicationContext(AppConfig.class);
🔸 파라미터로 넘긴 AppConfig.class도 스프링 빈으로 등록이 된다.
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
🔸순수 클래스라면 'class.hello.core.AppConfig'로 출력되어야 한다. 하지만 스프링이 CGLIB이라는 바이트코드를 조작하는 라이브러리를 사용하여 임의의 다른 클래스(AppConfig를 상속하는 자식클래스)를 만들고 새로 만든 임의의 클래스를 스프링 빈으로 등록한 것.
➡️ 쉽게 말하면 AppConfig를 상속하는 새로운 클래스를 만들고 @Bean이 붙은 메서드를 모두 빈으로 등록하는데, 스프링 빈이 존재하면 존재하는 빈을 반환하고 스프링 빈이 없으면 새로 생성해서 빈으로 등록하고 반환하게 한다.