싱글톤 패턴의 한계와 스프링 싱글톤

우리가 알고있는 싱글톤 패턴은 다음과 같다.

 

package com.company;

public class SingleTonInstance {

    private static SingleTonInstance INSTANCE;

	// 스프링은 기본적으로 synchronized 
    public synchronized static SingleTonInstance getINSTANCE() {
        
        if(INSTANCE == null){
           INSTANCE = new SingleTonInstance(); 
        }
        return INSTANCE;
    }
}

 

1. private 생성자를 갖고 있기 때문에 상속할 수 없다.

 

객체지향의 장점인 상속과 이를 이용한 다형성을 적용할 수 없다. 기술적인 서비스만 제공하면 상관없겠지만, 애플리케이션의 로직을 담고 있는 일반 오브젝트의 경우 싱글톤으로 만들었을때 객체지향적인 설꼐의 장점을 적용하기가 어렵다. 

 

2. 싱글톤은 테스트하기가 힘들다.

 

3. 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못함.

 

4. 자바 언어를 이용한 싱글톤 패턴기법은 서버환경에서는 싱글톤이 꼭 보장된다고 볼 수 없다.

여러 개의 JVM 에 분산돼서 설치가 되는 경우에도 각각 독립적으로 오브젝트가 생기기 때문에 싱글톤으로서의 가치가 떨어진다.

 

5. 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.

 

 

스프링 싱글톤 레지스트리

 

스프링은 서버환경에서 싱글톤이 만들어져서 서비스 오브젝트 방식으로 사용되는 것은 적극 지지한다. 하지만 자바의 기본적인 싱글톤 패턴의 구현 방식은 여러 가지 단점이 있기 때문에, 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.

 

그것이 싱글톤 레지스트리다. 스프링 컨테이너는 싱글톤을 생성, 관리, 공급하는 싱글톤 관리 컨테이너이기도 하다.

 

싱글톤 레지스트리의 장점은 스태틱 메소드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아니라 평범한 자바 클래스를 싱글톤으로 활용하게 해준다는 것이다. 평범한 자바 클래스라도 IoC 방식의 컨테이너를 사용해서 생성과 관계설정, 사용 등에 대한 제어권을 컨테이너에게 넘기면 손쉽게 관리되게 할 수 있다.

 

스프링 싱글톤 레지스트리 장점

1.스프링의 싱글톤 레지스트리 덕분에 싱글톤 방식으로 사용될 애플리케이션 클래스라도 public 생성자를 가질 수 있다. 

2. 테스트 환경에서 자유롭게 오브젝트를 만들 수 있고 테스트를 위한 목 오브젝트로 대체하는 것도 간단하다.

3. 싱글톤 패턴과 달리 스프링이 지지하는 개게지향적인 설계 방식과 원칙, 디자인 패턴등을 적용하는 데 아무런 제약이 없다는 점이다. 

 

주의사항

싱글톤은 머티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다. 따라서 상태 관리에 주의를 기울여야 한다. 기본적으로 stateless 한 방식으로 만들어져야 한다.

 

어떻게?

메소드 파라미터나, 메소드 안에서 생성되는 로컬 변수는 매번 새로운 값을 저장할 독립적인 공간이 만들어지기 때문에 싱글톤이라고 해도 여러 스레드가 변수의 값을 덮어쓸 일은 없다.