[기본] 싱글톤 컨테이너

메모

 

잘 설계한 객체는 컴파일 오류만으로 웬만한 오류가 잡힘

 

99% 싱글톤 사용

싱글톤을 사용하지 않을 때: http 요청에 맞춰 빈 라이프사이클을 정할 때(고객이 들어올 때 생성, 나갈 때 죽이는 등) 등

 

ctrl + shift + T : create new test

 

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

하면 AppConfig도 Bean 에 등록됨

 

---

싱글톤 패턴

클래스 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

싱글톤 패턴을 구현하는 데에는 여러가지 방법이 있다.

 

1. static으로 객체를 하나만 생성해두고 getInstance로 가져다 씀. private 생성자를 통해 외부에서 new 불가하게 함.
2. 객체를 처음에만 새로 생성하고 두 번째부터는 만들어둔 객체를 가져다 씀.
3. 기타..

싱글톤 패턴의 문제점

 

1. 싱글톤을 구현하는 코드 자체가 많이 들어간다.
2. 클라이언트가 구체 클래스에 의존하여 DIP를 위반하고 OCP를 위반할 가능성이 높아진다. (.getInstance()로 호출하기 때문)
3. 내부 속성을 변경하거나 자식 클래스를 만드는 등이 불가해 유연성이 떨어진다.
4. 안티패턴이라고도 불린다.

 

---

싱글톤 컨테이너

스프링 컨테이너는 직접 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.

싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

위의 싱글톤 패턴의 문제점을 해결하며 객체를 싱글톤으로 유지할 수 있다.

 

---

싱글톤 방식의 주의점

싱글톤 객체는 무상태(stateless)로 설계해야 한다.

특정 클라이언트에 의존적인 필드가 있으면 데이터가 꼬이며 멀티스레드 문제가 발생할 수 있다.

실제 실무에서도 종종 발생하는 문제이다.

 

---

@Configuration과 싱글톤

config 객체의 @Configuration 어노테이션을 빼면 어떤 문제가 발생할까?

 

스프링은 클래스의 바이트코드를 조작하는 라이브러리 "CGLIB" 를 사용한다.

CGLIB를 사용해 @Configuration을 붙인 클래스를 상속 받은 임의의 다른 클래스를 만들고 스프링 빈에 등록한다.

 

그 임의의 클래스가 아래와 같은 방법으로 싱글톤을 보장해준다.

@Bean
public Something something() {
	if(something가 스프링 컨테이너에 등록되어 있으면) {
    	return 스프링 컨테이너의 something;
    }
    else {
    	return 내가 작성한 로직으로 something 생성, 스프링 컨테이너에 등록, 반환;
    }
}

 

따라서 @Configuration을 붙이지 않으면 Bean은 싱글톤을 보장하지 않는다.