싱글톤 패턴

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

     +한 JVM 즉 하나의 java 서버 안에서는 객체 인스턴스가 딱 하나만, 생성 되도록 하는 것

• 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
  • private생성자를 사용해서 외부에서 임의로 new 키워드르 사용하지 못하도록 막아야 한다.

 

 

public class SingletonService {

    private static final SingletonService instance = new SingletonService();
}

static을 붙여서 필드 변수로 만들면, class 레벨에 올라가기 때문에, 딱 하나만 존재 하게 된다.

 

 

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance(){
        return instance;
    }
}

 

자바가 딱 뜰때, 바로 private static final SingletonService instance = new SingletonService( );를 실행 시켜서,

자기자신의 객체를 생성 시켜서 instance에 참조를 넣어 둔다. 그럼 자기 자신 인스턴스 객체를 딱하나 생성해서

 instance에 만 들어가 있는다.

 

public static void main(String[] args) {
    SingletonService singletonService = new SingletonService();
}

 하지만 누군가 임의로 또 다시 SingletonService 타입의 객체 인스턴스를 생성한다면?

   => 그래서, private 생성자를 사용한다.

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance(){
        return instance;
    }

    private SingletonService(){

    }

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출출");    }

}

 

 

 SingletonService 타입의 싱글톤 instance를 꺼 낼 수 있는 것은 getInstance밖에 없다.

 

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
2. 이 객체 인스턴스가 필요하면 오직 'getInstance( )'메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

싱클톤 패턴을 사용하는 테스트 코드를 보자

@Test
@DisplayName("싱클톤 패턴을 적용한 객체 사용")

void singletonServiceTest(){
    
    //private으로 생성자를 막아 두었다. 컴파일 오류가 발생한다.
    //new SinglltonService();
    
    
    //1.조회 :  호출할 때 마다 같은 객체를 반환
    SingletonService singletonService1 = SingletonService.getInstance();
    //2. 조회 : 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService2 = SingletonService.getInstance();

    //참조값이 같은 것을 확인
    System.out.println("singletonService1 = " + singletonService1);
    System.out.println("singletonService2 = " + singletonService2);
    
    
    //singletonService1 == singletonService2
    Assertions.assertThat(singletonService1).isSameAs(singletonService2);
    
    singletonService1.logic();
}

 

• private으로 new 키워드를 막아두었다.
• 호출할 때 마다 같은 객체 인스턴스를 반환하는 것을 확인 할 수 있다.

 

개발 팁★

- 웬만한 오류는 컴파일 오류만으로 오류를 잡아 낼 수 있도록 하는 것이 잘 설계된 프로그램이다.

- 객체 인스턴스 하나를 생성하는데 드는 비용이 1000정도라면 참조를 가져오는 비용은 1정도이다.

 

Assetions 메서드의 차이

.isEqual   =>.equals( )와 같다 즉, 논리적으로 같은 값인지를 비교하는 것.

.isSameAs => == 와 같다 즉, 물리적으로 같은 값인지를 비교하는 것.

 

스프링 컨테이너의 싱클톤 관리

스프링 컨테이너를 사용하면 AppConfig.class에 가서 return하는 값을 모두 싱글톤으로 변경 할 필요가 없다.

왜냐하면, 스프링 컨테이너를 사용하면 객체가 모든 싱크톤으로 사용되도록 알아서 관리해 주기 때문이다.

 

 

참고 : 싱글톤 패턴을 구현하는 방법은 여러가지가 있다. 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했다.

 

싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용 할 수 있다. 하지만 싱글톤 패턴은 다음과 같은 수 많은 문제점들을 가지고 있다.

 

*싱글톤 패턴 문제점*

• 싱글톤 패턴을 구현하는 코드 자체가 많이 늘어난다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. =>  DIP를 위반한다.

      구체클래스.getInstance로 객체 인스터스를 꺼내와야 해서, 구체 클래스에 의존하게 된다.

• 클라이언트가 구체 클래스에 의존해서 OCP원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다

      싱클톤은 이미 인스턴스를 받아 와서, 설정이 다 끝나버린다. 그래서 유연하게 테스트 하기 어렵다.

• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다
• 결론적으로 유연성이 떨어진다.

      DI를 적용하기 어렵다.

• 안티패턴으로 불리기도 한다.

 

=> 스프링 컨테이너를 싱클톤 컨테이너라고 하기도 한다.

 

 

 

[출처 : 김영한. 스프링 핵심 원리-기본편. 인프런]