싱글톤 스코프

들어가기 앞서 싱글톤 스코프의 싱글톤이 무엇인지 알아보자.

싱글톤

싱글톤이란 객체를 공유한다의 의미로 받아드렸다.
만약 메인 스피커의 볼륨을 조절하는 클래스를 만들었다면, 해당 객체를 만들고 볼류을 조절해야하지만, 객체가 계속해서 만들어지면 메인스피커의 본질이 흐려진다. 메인스프커가 여러개 생성되는 것이니까. 그래서 싱글톤을 사용하는데 싱글톤은 객체를 공유하여(주솟값이 동일한 객체) 모든 결과값을 공유하는 것이다.

사용이유 -> 수 많은 객체를 생성하게 되면 메모리 낭비와 효율성이 떨어지게 된다.

싱글톤 스코프란

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

• 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지된다.
• 싱글톤 빈의 하나의 공유 인스턴스만 관리한다.
  - private 생성자를 사용해서 임의로 new생성자를 사용하지 못하도록 막아야 한다.
• 해당 bean definition과 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환한다. (스프링이 싱글톤 객체를 관리한다.)
• 스프링 컨테이너 종료시 소멸 메서드도 자동으로 실행된다.

싱글톤 정리

싱글턴은 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미하고 단일 인스턴스는 싱글톤 빈의 캐시에 저장된다. 이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 개체를 반환한다. 또한 스프링 컨테이너의 기본값은 싱글톤이다.

중요한 점은 싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스 참조 주소값을 가진다.

싱글톤 패턴의 문제점

이렇게 공부했지만, 싱글톤 패턴의 문제점이 있어서 스프링에서는 싱글톤 패턴을 사용하지않는다.

문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다.
• 지정해서 가져오기 때문에 테스트하기 어렵다. (의존성)
• private 생성자를 사용하여 자식 클래스를 만들기 어렵기 때문에 유연성이 떨어진다.
• Application 초기 구동 시 인스턴스 생성
  • 싱글톤 빈은 기본적으로 애플리케이션 구동 시 생성되므로 싱글톤 빈이 많을 수록 구동 시간이 증가할 수 있다.

해결

하지만, 정말 안 쓰지않는다. 단지 싱글톤 패턴 문제를 스프링의 싱글톤 컨테이너가 해결해서 사용한다.

싱글톤 컨테이너는 객체 인스턴스를 싱글톤으로 관리하는데

• 스프링 컨테이너는 싱글톤 컨테이너 역활을 한다.