👨🏻💻스프링 없는 컨테이너만 사용한 객체 생성 방법
com.example.week4 패키지에 SingletonTest.java를 클래스로 만듭니다.
결과값
-
같은 memberService를 사용하지만 뒤에 붙은 주소값이 다른걸 볼 수 있다.
-
수 많은 객체를 생성하게 되면 위에 방식은 메모리 낭비와 효율성이 떨어지게 된다.
위 문제에 대한 해결방법으로 싱글톤 패턴을 사용할 수 있다.
👨🏻💻싱글톤 패턴 적용 코드
com.example.week4에 singleton 패키지를 생성한다.
singleton 패키지에서 SingletonService.java 파일을 생성하고, 아래 코드를 작성한다.
-
static 영역에 객체 인스턴스를 미리 1개 생성한다.
-
객체 인스턴스가 필요한 경우 getInstance() 메서드를 통해서만 조회할 수 있도록 한다.
-
이 메서드를 호출하면 항상 같은 static instance를 호출하게 된다.
-
외부에서 생성자를 new로 새로 생성되는 것을 방지하기 위해 private 생성자로 생성한다.
com.example.week4에 SingletonTest.java 파일을 수정합니다.
결과값
- 같은 SingletonService를 사용하는 모든 객체는 같은 인스턴스를 바라보게 된다.
스프링 컨테이너의 기본값은 싱글톤이다.
위 코드처럼 직접 static 인스턴스를 직접 만들지 않아도 됩니다.
👨🏻💻싱글톤 패턴의 문제점
-
싱글톤 패턴을 구현하는 코드 자체가 많다.
-
의존관계상 클라이언트가 구체 클래스에 의존한다.
-
지정해서 가져오기 때문에 테스트하기 어렵다.
-
private 생성자를 사용하여 자식 클래스를 만들기 어렵기 때문에 유연성이 떨어진다.
-
속성 공유
- 멀티쓰레드 환경에서 싱글톤 객체의 속성은 여러 쓰레드에 의해 바뀔 수 있다.
- A 쓰레드에선 속성 값을 x로 바꾸고 출력하는 과정에서 B 쓰레드가 속성 값을 y로 바꾸면 쓰레드 A에선 예상하지 못한 값이 나올 수 있다.
(1개의 인스턴스에서 속성 값을 공유하기 때문에 발생하는 문제점) - 가급적 읽기만 가능해야 한다.
-
Application 초기 구동 시 인스턴스 생성
- 싱글톤 빈은 기본적으로 애플리케이션 구동 시 생성되므로 싱글톤 빈이 많을 수록 구동 시간이 증가할 수 있다.
👨🏻💻싱글톤 패턴 문제를 싱글톤 컨테이너가 해결해줍니다.
객체 인스턴스를 싱글톤으로 관리한다.
-
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
-
싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
-
스프링 컨테이너의 위 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하며 객체를 싱글톤으로 유지할 수 있다.
dependencyConfig.java 파일을 수정합니다.
👨🏻💻dependencyConfig.java 수정 전
👨🏻💻dependencyConfig.java 수정 후
-
@Configuration 과 @Bean 애너테이션을 추가해줍니다.
-
@Bean을 통해 스프링 컨테이너에 등록됩니다.
-
com.example.week4에 SingletonTest.java 파일을 수정한다.
결과값
👨🏻💻싱글톤 방식의 주의점
- 싱글톤 방식은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태로 설계해야 한다.
- 특정 클라이언트가 값을 변경할 수 있으면 안된다.
- 읽기만 가능해야 한다.
- 스프링 빈의 공유 값을 설정하면 장애가 발생할 수 밖에 없다.
