웹 애플리케이션과 싱글톤
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
public void pureContainer() throws Exception {
AppConfig appConfig = new AppConfig(); // 순수 자바 외부 설정 파일
//1. 조회: 호출 할 때마다 객체를 생성
MemberService memberService1 = appConfig.memberService();
//2. 조회: 호출 할 때마다 객체를 생성
MemberService memberService2 = appConfig.memberService();
//참조값이 다른 것을 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
//memberService1 != memberService2
Assertions.assertThat(memberService1).isNotSameAs(memberService2);
}
- ex) 여러 고객들이 회원 가입을 위해서 memberService를 서버에 요청한다.
- 스프링 없는 순수 자바 DI 컨테이너인 AppConfig는 서비스 요청이 올 때마다 객체를 생성한다.
- 수많은 고객들의 요청이 들어오면 많은 객체의 생성으로 메모리 낭비가 심하다.
- 이 문제를 해결하기 위해 해당 객체가 딱 1개만 생성되고 공유하도록 설계한 싱글톤 패턴을 사용
Singleton Pattern
public class SingletonService {
// 1. static area에 객체 instance를 미리 하나 생성해서 올려둔다.
private static final SingletonService instance = new SingletonService();
// 2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회
public static SingletonService getInstance(){
return instance;
}
// 3. 딱 1개의 객체 인스턴스만 존재해야 한다.
private SingletonService(){
}
public void logic(){
System.out.println("싱글톤 객체 로직 호출");
}
}
- static area에 객체 instance를 미리 하나 생성해서 올려둔다.
- 프로그램 실행 시 Class Loader는 static 키워드를 가진 모든 것들을 static 영역에 메모리를 할당한다.
- 객체 생성 시 static 영역에 이미 생성된 객체 instance를 가져와서 사용하기 때문에 하나의 인스턴스만 생성되고 공유한다.
- public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회할 수 있다.
- 딱 1개의 객체 인스턴스만 존재해야 한다.
- 생성자를 private으로 선언해서 외부에서 new 키워드를 통해 객체 생성을 못하게 막는다.
싱글톤 패턴의 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존 관계 상 클라이언트가 구체 클래스에 의존한다. - DIP 위반
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 테스트 코드 작성이 어렵다.
- 내부 속성을 변경하거나 초기화하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어렵다.