싱글톤 패턴은 클래스의 인스턴스가 딱 1개만 생성되도록 보장하는 디자인 패턴이다.
public class SingletonService {
// 1. static(class) 영역에 객체를 딱 1개만 생성하고 참조 값을 저장한다.
private static final SingletonService instance = new SingletonSservice();
// 2. 객체 인스턴스는 오직 public의 getInstance() 메서드로만 조회 가능하다.
public static SingletonService getInstance() {
return instance;
}
// 3. 생성자를 private으로 선언하여 외부에서의 인스턴스 생성을 막는다.
private SingletonService() {}
public void login() {
System.out.println("싱글톤 객체 로직 호출");
}
}
private
생성자를 통해 외부에서 new
로 인스턴스를 생성하지 못하도록 할 수 있다.웹 애플리케이션은 보통 여러 고객의 요청이 동시에 전달된다. 각각의 요청에 대해 매번 새로운 객체를 생성하면 메모리가 낭비되고, 지연 시간이 발생할 수 있다. 따라서 필요로 하는 객체를 딱 하나만 생성하고, 이 객체를 공유하도록 설계하는 것이 좋다.
private
생성자로 자식 클래스를 만들기 어렵다.스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체를 싱글톤으로 관리한다.
여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 무상태로 설계해야 한다.
스프링은 클래스의 바이트 코드를 조작하는 라이브러리를 사용한다.
@Test
void configurationDeep() {
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println(String.format(
"bean = %s", bean.getClass();
));
}
bean = class hello.core.AppConfig$$EngancerBySpringCGLIB$$bd479d70
AppConfig
가 순수한 클래스라면 class hello.core.AppConfig
가 출력되어야 한다.XxxCGLIB
가 붙으면서 상당히 복잡해졌다.스프링 컨테이너는 싱글톤 레지스트리이다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링은 자바 코드까지 조작하지 못한다. 따라서 스프링은 클래스의 바이트 코드를 조작하는 라이브러리를 사용한다.
@Bean
이 붙은 메서드마다 스프링 빈 존재 여부를 확인한다.@Configuration
과 @Bean
의 조합으로 싱글톤을 보장하는 경우는 정적이지 않은 메서드일 때이다.@Bean
을 사용하면 싱글톤을 위한 지원을 받지 못한다.크게 고민할 것 없다. 스프링 설정 정보는 항상
@Configuration
을 사용하자.