[헤드퍼스트 디자인 패턴] 05. 싱글턴 패턴

📚 헤드퍼스트 디자인 패턴 (에릭 프리먼 외, 한빛미디어)

 

1. 싱글턴 패턴의 정의

싱글턴 패턴(Singleton Pattern)

싱글턴 패턴(Singleton Pattern)은 클래스의 인스턴스를 단 하나만 만들고, 그 인스턴스로의 전역 접근을 제공한다.

 

싱글턴 패턴이 필요한 예

스레드 풀(Thread pool), 캐시(Cache), 대화상자, 사용자 설정, 레지스트리 설정을 처리하는 객체, 로그 기록용 객체, 디바이스 드라이버 등의 객체는 하나만 있어도 잘 돌아간다.

오히려 이러한 객체를 쓸 때 인스턴스가 2개 이상이면 프로그램이 이상하게 돌아가거나, 자원을 불필요하게 잡아먹거나, 결과에 일관성이 없어지는 등의 심각한 문제가 생길 수 있다.

이러한 문제를 해결하기 위해 전역 변수를 사용할 수도 있지만, 전역 변수를 사용하는 것에는 여러가지 단점이 존재한다.

전역변수에 객체를 대입하면 애플리케이션이 시작될 때 객체가 생성된다.

만약 그 객체가 자원을 많이 차지한다고 가정하자.

애플리케이션이 끝날 때까지 그 객체를 한 번도 쓰지 않는다면 괜히 자원만 잡아먹는 쓸데없는 객체가 되고 말 것이다.

반면 싱글턴 패턴을 사용하면 필요할 때만 객체를 만들 수 있다.

이처럼 싱글턴 패턴을 사용하면 전역 변수를 사용할 때와 마찬가지로 객체 인스턴스를 어디서든지 엑세스할 수 있게 만들 수 있으면서도 전역 변수를 쓸 때의 여러 단점을 해결할 수 있다.

 

2. 고전적인 싱글턴 패턴 구현법

public class Singleton {
    // Singleton 클래스의 하나뿐인 인스턴스를 저장하는 static 변수
    private static Singleton uniqueInstance;

    // private 생성자로 클래스 외부에서의 객체 생성을 막는다.
    private Singleton() {}     

    // Singleton 클래스의 인스턴스를 만들어서 리턴하는 static 메서드
    public static Singleton getInstance() {
        // 아직 인스턴스가 만들어지지 않았다면, private으로 선언된 생성자를 사용해서 Singleton 객체를 만든 다음 uniqueInstance에 그 객체를 대입한다.
        // 이러면 인스턴스가 필요한 상황이 오기 전까지는 인스턴스를 생성하지 않는다. 이러한 방법을 '게으른 인스턴스 생성(lazy instantiation)'이라 한다.
        if(uniqueInstance == null) {
            uniqueInstance = new Singleton();
        }         

        return uniqueIntance;   
    } 
}

클래스의 생성자를 private으로 선언하여 클래스 외부에서의 객체 생성을 막는다.

static 메서드인 getInstance()를 통해서만 인스턴스를 반환한다.

이때 이미 생성된 인스턴스가 있으면 해당 인스턴스를 반환하고, 생성된 인스턴스가 없으면 새로 생성해서 반환한다.

 

3. 멀티스레딩 문제 살펴보기

위와 같은 고전적인 싱글턴 패턴은 멀티스레딩 환경에서 문제가 발생할 수 있다.

아직 객체 인스턴스가 생성되지 않은 상황에서 여러 스레드에서 동시에 getInstance() 메서드를 호출하면 각 스레드에 서로 다른 두 개의 객체 인스턴스가 반환될 수 있다.

다음 그림과 같은 상황이다.

 

4. 멀티스레딩 문제 해결하기

대부분의 자바 애플리케이션을 지원하기 위해서는 멀티스레드 환경에서도 싱글턴이 돌아가도록 만들어야 한다.

멀티스레딩 문제를 해결할 수 있는 방법 세 가지를 살펴보자.

 

방법 1. getInstance() 메서드 동기화하기

public class Singleton {

    private static Singleton uniqueInstance;

    private Singleton() {}

    // getInstance() 메서드에 synchronized 키워드를 추가하면 한 스레드가 메서드 사용을 끝내기 전까지 다른 스레드는 기다려야 한다.
    // 즉, 2개의 스레드가 이 메서드를 동시에 실행하는 일은 일어나지 않게 된다.
    public static synchronized Singleton getInstance() {

        if(uniqueInstance == null) {
            uniqueInstance = new Singleton();
        }

        return uniqueInstance;
    }
}

 

getInstance() 메서드에 synchronized 키워드를 추가하여 메서드를 동기화할 수 있다.

그렇게 되면 한 스레드가 메서드 사용을 끝내기 전까지는 다른 스레드는 기다려야 한다.

이를 통해 여러 스레드가 이 메서드를 동시에 실행하여 여러 인스턴스를 생성하는 것을 막을 수 있다.

하지만 메서드를 동기화하면 속도 문제가 생긴다.

일반적으로 메서드를 동기화하면 성능이 100배 정도 저하된다.

만약 getInstance() 메서드가 애플리케이션에서 병목으로 작용한다면 다른 방법을 생각해봐야 한다.

또 조금 더 생각해보면, 동기화가 필요한 시점은 이 메소드가 시작될 때뿐이라는 사실을 알 수 있다.

일단 uniqueInstance 변수에 Singleton 인스턴스를 대입하고 나면 굳이 메서드를 동기화된 상태로 유지할 필요가 없다.

 

방법 2. 인스턴스가 필요할 때 생성하지 말고 처음부터 생성하기

public class Singleton {

    // 정적 초기화 부분(static initializer)에서 Singleton의 인스턴스를 생성한다.
    private static Singleton uniqueInstance = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() {

        // 이미 만들어진 인스턴스를 리턴만 하면 된다.
        return uniqueInstance;
    }
}

 

위 방법을 사용하면 클래스가 로딩될 때 JVM에서 Singleton의 하나뿐인 인스턴스를 생성해준다.

JVM에서 하나뿐인 인스턴스를 생성하기 전까지 그 어떤 스레드도 uniqueInstance 정적 변수에 접근할 수 없다.

하지만 이 방법은 게으른 인스턴스 생성을 할 수 없고, 처음부터 끝까지 인스턴스를 가지고 있어야 한다는 단점이 있다.

 

방법 3. DCL(Double-Checked Locking)을 써서 getInstance() 메서드에서 동기화되는 부분 줄이기

public class Singleton {

    // 정적 변수에 volatile 키워드를 사용하면 멀티스레딩을 쓰더라도 uniqueInstance 변수가 Singleton 인스턴스로 초기화되는 과정이 올바르게 진행된다.
    private volatile static Singleton uniqueInstance;

    private Singleton() {}

    public static Singleton getInstance() {

        // 인스턴스가 있는지 확인하고, 없으면 동기화된 블록으로 들어간다.
        if(uniqueInstance == null) {

            // 처음에만 동기화된다.
            synchronized (Singleton.class) {

                // 블록 내에서 다시 한 번 인스턴스가 있는지 확인하고, 없을 때에만 인스턴스를 생성한다.
                if(uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }

        return uniqueInstance;
    }
}

 

DCL(Double-Checked Locking)을 사용하면 인스턴스가 생성되어 있는지 확인한 다음, 생성되어 있지 않을 때에만 동기화할 수 있다.

이러면 처음에만 동기화하고 나중에는 동기화하지 않아도 된다.

단, DCL은 자바 1.4 이전 버전에서는 쓸 수 없다.

자바 1.4보다 낮은 버전의 JVM 중에는 volatile 키워드를 써도 DCL에서 동기화가 제대로 안 되는 일이 많다.

 

5. 싱글턴 패턴의 다른 문제 살펴보기

1. 클래스 로더가 2개 이상일 때 생기는 문제

클래스 로더마다 서로 다른 네임스페이스를 정의하기 때문에 클래스 로더가 2개 이상이라면 같은 클래스를 여러 번(각 클래스 로더마다 한 번씩) 로딩할 수도 있다.

이때문에 싱글턴의 인스턴스가 여러개 만들어지는 문제가 발생할 수 있다.

따라서 클래스 로더가 여러 개일 때에는 싱글턴을 조심해서 사용해야 한다.

클래스 로더를 직접 지정한다면 이 문제를 피할 수는 있다.

 

2. 리플렉션, 직렬화, 역직렬화 문제

리플렉션, 직렬화, 역직렬화도 싱글턴에서 문제가 될 수 있다.

TODO 리플렉션, 직렬화, 역직렬화 공부하기

 

3. 느슨한 결합 원칙의 위배

느슨한 결합 원칙에 따르면 "상호작용하는 객체 사이에서 최대한 느슨한 결합을 추구"해야 한다.

싱글턴에 의존하는 객체는 전부 하나의 객체에 단단하게 결합되기 때문에 싱글턴을 사용하다 보면 이런 원칙을 위배하기 쉽다.

싱글턴을 바꾸면 연결된 모든 객체도 바꿔야 할 가능성이 높기 때문이다.

 

4. 상속이 불가능한 문제

싱글턴의 서브 클래스(자식 클래스)를 만들 때 가장 먼저 마주치는 걸림돌이 바로 생성자가 private으로 선언되어 있다는 점이다.

private으로 지정된 생성자를 가진 클래스는 확장할 수 없기에 생성자를 public 또는 protected로 선언해야 한다.

그러면 다른 클래스에서 인스턴스를 만들 수 있게 되므로 더는 싱글턴이 아니게 된다.

또 다른 문제는 싱글턴은 정적 변수를 바탕으로 구현하기 때문에 서브클래스를 만들면 모든 서브클래스가 똑같은 인스턴스 변수를 공유하게 된다는 점이다.

따라서 서브클래스를 만들려면 베이스 클래스에서 레지스트리 같은 걸 구현해야 한다.

 

6. 싱글턴 패턴의 다른 문제 해결하기

방법 1. Enum 사용하기

지금까지 논의한 동기화 문제, 클래스 로딩 문제, 리플렉션, 직렬화와 역직렬화 문제 등은 enum으로 싱글턴을 생성함으로써 해결할 수 있다.

public enum Singleton {
    UNIQUE_INSTANCE;
}

public class SingletonClient {
    public static void main(String[] args) {

        Singleton singleton = Singleton.UNIQUE_INSTANCE;

        // 여기서 싱글턴 사용
    }
}

 

이 방법은 Eager Initialization으로 인한 문제가 생길 수 있으며, 싱글턴이 enum 외의 클래스를 상속해야 하는 경우에는 사용할 수 없다는 문제가 있다.

 

방법 2. Lazy Holder 사용하기

public class Singleton {

    private Singleton() {}

    // private static inner class
    private static inner class LazyHolder {

        // Lazy Holder 클래스 초기화 과정에서 JVM이 Tread-Safe하게 instance를 생성한다.
        private static final Singleton uniqueInstance = new Singleton();
    }

    public static Singleton getInstance() {

        // LazyHolder의 uniqueInstance에 접근하여 반환한다.
        return LazyHolder.uniqueInstance;
    }
}

 

이 방식은 Eager Initialization을 개선한 방식이다.

싱글턴의 getInstance() 메서드가 호출되면 LazyHolder의 uniqueInstance 변수에 접근하는데, 이때 LazyHolder가 static inner class이기 때문에 클래스의 초기화 과정이 이루어지면서 uniqueInstance 객체가 생성된다.

JVM은 클래스의 초기화 과정에서 원자성을 보장한다.

즉, uniqueInstance는 getInstance() 메서드 호출 시 LazyHolder 클래스의 초기화가 이루어지면서 JVM에 의해 원자성이 보장된 상태로 단 한 번만 생성되고, final 변수이기 때문에 이후로 다시 uniqueInstance에 다른 객체가 할당되는 것을 막을 수 있다.

getInstance() 메서드에 synchronized를 사용하지 않아도 JVM에 의해 원자성이 보장되므로 이러한 JVM의 특성을 활용하여 성능 저하를 막는 방식이다.

역직렬화 수행 시 새로운 객체가 생성되고, 리플렉션을 이용해 내부 생성자 호출이 가능하다.

정리하자면, 직렬화 등 안정성이 중요시되는 환경에서는 enum을, 성능이 중요시되는 환경에서는 Lazy Holder를 사용하면 된다.

 

(참고) https://github.com/IT-Book-Organization/HeadFirst-DesignPattern/tree/main/Chapter_05