[Spring] SingleTon이란

싱글턴 패턴

-소프트웨어 디자인 패턴에서 싱글턴 패턴을 따르는 클래스는 생성자가 여러차례 호출되어도,

실제로 생성되는 객체는 하나이고, 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.

 

싱글턴 패턴을 사용하는 이유

만약 우리가 만들었던 DI컨테이너인 요청을 할 때마다 새로운 객체를 생성한다

요청이 엄청나게 많은 트래픽 사이트에서는 객체를 새로 생성하게 되면 메모리 낭비가 심하다

 

구현 예제

-static 객체를 통해서 1개의 객체만 생성 할수 있도록 한다.

-static 메소드를 통해, 외부에서 생성할수있도록 제한한다.

-new 연산자를 통해서 객체를 만드는 것을 private 생성자를 통해서 제한한다.

 

싱글턴 패턴 문제점

-싱글턴 패턴을 구현하는 코드 자체가 많다. (값이나 특정 속성에 따라서 별도로 지정해줘야하기 때문이다.)

-클라이언트가 구체 클래스에 의존한다.

-테스트가 어렵다 (변경되면 연관된 시스템 전부 메모리에 재 로딩)

-내부 속성을 변경 or 초기화가 어렵다

-자식 클래스 만들기 어렵다

-스프링 컨테이너에서 위의 단점을 모두 해결해준다.

 

-> 싱글턴 패턴은 쉽게 얘기하면, 유연성이 떨어진다는 문제가 있고
스프링에서는 이러한 문제점을 해결하여 싱글턴 문제를 해결, 사용한다.

 

 

스프링에서는 싱글턴 관련 코드를 작성하지 않아도, 빈 당 객체를 1개 설정한다.

(싱글턴은 stateful 하게 설계하면 안된다. 즉 stateless하게 설계를 진행해야한다.)

 

싱글턴은 쉽게 얘기하면, 요청 때마다 객체를 생성하는 것이 아니라 1개의 인스턴스만 호출시에 반환하는 것을 의미하며,

수많은 객체들이 필요할때 일일히 작성해야하는 번거로움과, 클라이언트가 구체 클래스에 의존한다는 것, 유연성이 떨어진다는 단점이 존재한다 -> 스프링 컨테이너를 통해서 해결된다.

 

스프링의 기본 빈 등록 방식은 싱글턴이고, prototype scope등 다른 방식으로도 설정할 수 있도록 존재한다.

 

<스프링 컨테이너 싱글턴 유지 방법>

Configuration : 스프링 컨테이너가 싱글톤 방식을 사용하는 메커니즘의 핵심을 해당 어노테이션에있다.

설정 파일을 만들기 위하여 클래스에 이 어노테이션을 붙이는 데

@Configuration 어노테이션이 붙은 클래스를 출력하면, CGLIB로 출력이 된다.

 

CGLIB는, 프록시 객체로도 사용이 된다. 즉 바이트코드 조작 라이브러리이다.

Appconfig를 상속받은 임의의 클래스를 생성, 빈으로 등록 제공한다.

 

CGLIB의 내부기술은 알수 없지만, 스프링 빈으로 등록하고 반환하는 코드가 스프링 컨테이너에 등록이 되어있다면

찾아서 반환하라~ 뭐 이런식으로 되어있을 것이다.

 

즉 스프링 빈이 싱글턴을 보장해주는 것은 아니다.

싱글턴 보장은 스프링에서 사용하는 바이트조작라이브러리 CGLIB이고

Configuration을 사용하면 해당 라이브러리를 써서, 붙은 클래스를 상속받는 다른 클래스를 생성 및 싱글턴 관리를 해준다.