[Spring] 싱글톤 (feat. 싱글톤을 구현하는 여러 방식)

 

 

 

 

 

싱글톤

싱글톤 패턴은 어떤 클래스의 인스턴스가 오직 하나만 생성되는 것을 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 패턴입니다.

 

 

싱글톤을 구현하는 여러가지 방법이 있는데, 하나하나 살펴보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

 

1. Eager Initialization (이른 초기화, Thread - safe)

Eager Initialization은 가장 간단한 형태의 싱글톤 구현 방법입니다.

public class Singleton {
    
    private static final Singleton instance = new Singleton();//클래스 로딩 시점에 생성
    
    private Singleton(){} //private 생성자로 외부 클래스로부터 인스턴스가 생성되는것을 차단한다.
 
    public static Singleton getInstance(){
        return instance;
    }
}

 

 

클래스의 인스턴스를 클래스 로딩 시점에 생성하는 방법으로, Thread-safe합니다.

그러나 애플리케이션에서 해당 인스턴스를 사용하지 않더라도 인스턴스를 생성하기 때문에 낭비가 발생할 수 있습니다..

 

 

이 방법은 싱글톤 클래스가 다소 적은 리소스를 다룰 때 사용해야 하며, File System이나 Database Connection 등 큰 리소스들을 다루는 싱글톤을 구현할 때는 다른 방법을 사용하는 것이 좋습니다.

게다가 Exception에 대한 Handling도 제공하지 않습니다.

 

 

 

 

 

 

 

 

 

 

 

 

2. Static Block Initialization (정적 블럭 초기화, Thread - safe)

 

Static Block Initialization은 1번에서 살펴본 Eager Initialization과 유사하지만,

static block을 통해서 Exception Handling에 대한 옵션을 제공합니다.

 

public class Singleton {
 
    private static Singleton instance;
    
    private Singleton(){}
    
   
    static{
        try{
            instance = new Singleton();
        }catch(Exception e){
            throw new RuntimeException("Exception occured in creating singleton instance");
        }
    }
    
    public static Singleton getInstance(){
        return instance;
    }
}

Exception에 대한 Handling이 추가되었다는 것 말고는 Eager Initialization과 동일합니다.

 

 

 

 

 

 

 

 

 

 

 

3. Lazy Initialization (정적 블럭 초기화)

Lazy Initialization은 앞선 두 방식과는 달리 나중에 초기화하는 방법입니다.

이는 전역에서 접근 가능한 getInstance() 메소드를 호출할 때에 인스턴스가 없다면 생성합니다.

public class Singleton {
 
    private static Singleton instance;
    
    private Singleton(){}
    
    public static Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}

이 방법을 사용한다면 1, 2번이 가지고 있었던 문제점인 '사용하지 않았을 경우 인스턴스가 낭비'에 대한 해결책이 되지만, 다른 문제점이 발생합니다.

 

 

 

 

멀티스레드(multi-thread) 환경에서의 동기화 문제

만약 인스턴스가 생성되지 않은 시점에서 여러 쓰레드가 동시에 getInstance()를 호출한다면 예상치 못하게 많은 인스턴스가 생성될 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

4. Lazy Initialization with synchronized

(동기화 블럭을 사용한 게으른 초기화, Thread - safe)

 

멀티 스레드 환경에서의 동기화 문제를 해결하기 위해 getInstance() 메소드에 synchronized를 걸어두어 Thread-safe를 보장해주는 방법입니다.

public class Singleton {
 
    private static Singleton instance;
    
    private Singleton(){}
    
    public static synchronized Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
    
}

 

이 방법을 사용하면 1,2번이 가지고 있던 문제점인 인스턴스 낭비와, 3번이 가지고 있던 Thread-safe하지 않다는 단점을 모두 해결할 수 있습니다.

 

그러나 synchronized 키워드 자체에 대한 비용이 크기 때문에 싱글톤 인스턴스 호출이 잦은 어플리케이션에서는 성능이 떨어지게 됩니다.

 

 

 

 

 

 

 

 

 

 

5. Lazy Initialization, Double Checking Locking (DCL, Thread - safe)

인스턴스가 생성되어 있지 않은 시점에만 synchronized가 실행되게끔 구현하는 방식입니다.

public class Singleton {
    private volatile static Singleton instance;

    private Sigleton() {}

    // Lazy Initialization. DCL
    public Singleton getInstance() {
      if(instance == null) {
         synchronized(Singleton.class) {
            if(instance == null) {
               instance = new Singleton(); 
            }
         }
      }
      return instance;
    }
}

 

위 코드에서 `volatile`키워드가 등장하는데, volatile 키워드를 사용하면 멀티스레드 환경에서도 객체가 Sigleton 인스턴스로 초기화 되는 과정이 올바르게 진행되도록 할 수 있습니다.

 

 

[참고]

Volatile

 

 

 

 

 

 

 

 

 

 

 

6. Lazy Initialization, LazyHolder (게으른 홀더, Thread - safe)

 

Bill Pugh Singleton Implementaion 라고도 부릅니다.

 

Bill Pugh가 고안한 방식으로, inner static helper class를 사용하는 방식인데,

volatile 이나 synchronized 키워드 없이도 동시성 문제를 해결하기 때문에 성능이 뛰어나며 현재 가장 널리 쓰이는 싱글톤 구현 방법입니다.

public class Singleton {

    private Singleton() {}


    private static class InnerInstanceClazz {
        // 클래스 로딩 시점에서 생성
        private static final Singleton uniqueInstance = new Singleton();
    }

    public static Singleton getInstance() {
        return InnerInstanceClazz.uniqueInstance;
    }
    
}

 

방법

• private inner static class를 두어 싱글톤 인스턴스를 갖게 합니다
• InnerInstanceClazz클래스는 Singleton 클래스가 Load 될 때에도 Load 되지 않다가 getInstance()가 호출됐을 때 비로소 JVM 메모리에 로드되고, 인스턴스를 생성하게 됩니다.

 

 

 

 

 

 

 

 

7. Enum Singleton (Thread - safe)

앞서 1~6번에서 살펴본 방법들은 사실 완전히 안전할 수는 없습니다.

Java의 리플렉션(Reflection)을 통해서 싱글톤을 파괴할 수 있기 때문입니다.

추가로 직렬화 - 역직렬화 과정에서도 싱글톤이 파괴될 수 있습니다.

 

이에 Enum으로 싱글톤을 구현하는 방법이 등장합니다.

public enum Singleton {
    INSTANCE; 
}

 

 

Enum 인스턴스의 생성은 기본적으로 Thread-safe 합니다.

 

Enum 을 사용한 방식의 장점은 아주 복잡한 직렬화 상황이나, 리플렉션 공격에도 제 2의 인스턴스가 생성되는 것을 막아준다데 있습니다.

단, 만들려는 싱글턴이 Enum 외의 클래스를 상속해야 하는 경우에는 사용할 수 없으며, 또한 Android 같이 Context 의존성이 있는 환경일 경우, 싱글턴의 초기화 과정에 Context 라는 의존성이 끼어들 가능성이 있습니다.

 

 

 

 

 

 

 

 

 

 

 

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 필요합니다.
• 의존관계상 클라이언트가 구체 코드에 의존하므로 DIP(의존관계 역전 원칙)를 위반합니다 ( ex : 구체클래스.getInstance())
• 클라이언트가 구체 코드에 의존하므로 OCP(개방-폐쇄 원칙)를 위반할 가능성이 높습니다.
• 테스트하기 어렵습니다
• 내부 속성을 변경하거나 초기화하기 어렵습니다
• private 생성자로 자식 클래스를 만들기 어렵습니다.
• 결론적으로 유연성이 떨어집니다

 

위와 같은 이유들 때문에 안티패턴이라 불리기도 합니다.

 

 

 

 

 

 

 

 

 

 

싱글톤 컨테이너

스프링 컨테이너는 위와 같은 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리하여 줍니다.

 

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리합니다.
  • 싱글톤 컨테이너의 생성 과정을 보면, 컨테이너는 스프링 빈 객체를 하나만 생성해서 관리합니다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 합니다.
  • 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 합니다.
• 스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있습니다.
• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 됩니다.
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있습니다.

 

 

 

 

 

 

 

 

 

싱글톤 방식의 주의점

싱글톤 방식에서는 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에

싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됩니다.

 

무상태(stateless)로 설계해야 합니다

 

 

 

 

 

무상태란?

• 특정 클라이언트에 의존적인 필드가 있으면 안됩니다.
• 값을 변경할 수 있는 필드가 있으면 안됩니다.
• 가급적 읽기만 가능해야 합니다.
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal등을 사용해야 합니다.

 

 

 

 

 

 

 

 

Reference

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

[생성 패턴] 싱글톤(Singleton) 패턴을 구현하는 6가지 방법

 

[Java] Enum과 싱글톤(Singleton)