[Java] Thread-Safe한 Singleton 객체

출처

ChatGPT

https://simyeju.tistory.com/121

Java] Multi Thread 환경에서 Singleton 패턴을 Thread Safe하게 사용하기

https://www.initgrep.com/posts/design-patterns/thread-safety-in-java-singleton-pattern

Explore Different Ways to Implement Thread-Safe Singleton Pattern in Java

F-Lab Android Pepe 멘토님

---

관련 개념

Singleton 패턴

객체를 오직 하나만 생성하도록 보장하는 디자인 패턴. 프로그램 전체에 하나의 인스턴스만 필요하고, 그 인스턴스에 전역적으로 접근할 수 있도록하는 상황에서 유용하다.

-> OOP 환경에서 전역 변수를 사용하고 싶어서 나온 것

Singleton 객체

싱글톤 패턴에 따라 생성된 객체. 해당 클래스의 유일한 인스턴스를 의미한다. 

싱글톤 패턴을 사용하는 대표적인 경우

• 설정 관리 : 애플리케이션 전반에 걸쳐 일정한 설정 값을 유지할 필요가 있을 때
• 로그 기록 : 프로그램 내의 모든 로그가 동일한 로그 파일에 기록되어야 할 때
• 데이터베이스 연결 관리 : 데이터베이스 연결을 하나의 인스턴스로 관리하고 공유할 때

Thread-Safe 의미

멀티스레드 환경에서 여러 스레드가 동시에 같은 자원에 접근하거나 수정하려고 할 때도, 프로그램의 실행 결과가 정확하고 예측 가능한 상태로 유지되는 것

• 관련 글 -> [OOP] 객체의 불변성과 스레드 안정성

 

싱글톤 객체를 Thread-Safe하게 만들어야 하는 이유

멀트스레드 환경에서 인스턴스의 유일성을 보장하기 위해서. 멀티스레드 환경에서는 여러 스레드가 동시에 getInstance() 메소드를 호출할 수 있으며, 이때 객체가 여러 번 생성되는 문제가 발생할 수 있기 때문에 신중한 처리가 필요하다.

1. 동시성 문제

싱글톤 클래스의 인스턴스를 생성할 경우, 여러 스레드가 동시에 getInstance() 메소드를 호출하면 아직 인스턴스사 생성되지 않았을 때 여러 스레드가 동시에 생성 시도를 할 수 있다.

이 경우, 서로 다른 스레드가 각기 다른 싱글톤 인스턴스를 생성하게 될 수 있어 싱글톤의 유일성 원칙이 깨진다.

2. 데이터 일관성 유지

싱글톤 객체는 주로 설정, 로깅, 데이터베이스 연결, 리소스 관리 등의 목적으로 사용되며, 여러 부분에서 접근이 일어나므로 데이터 일관성이 중요하다.

• 데이터 일관성 Data Consistency : 여러 스래드 또는 프로세스가 동시에 접근하거나 수정하는 데이터가 항상 정확하고 예측 가능한 상태로 유지되는 것

Thread-Safe하지 않다면, 여러 스레드가 동시에 접근해 데이터를 변경하려 할 때, 잘못된 데이터 상태가 발생하거나 경합 상태(race condition)이 일어날 수 있다.

• 경합 상태 Race Condition : 여러 스레드 또는 프로세스가 동시에 공유 자원에 접근하거나 수정하려 할 때 발생하는 문제. 작업의 실행 순서가 실행마다 달라지면서 예측할 수 없는 결과를 초래할 수 있다.

3. 리소스 낭비 방지

싱글통 패턴의 주요 장점은 객체를 한 번만 생성해 메모리와 같은 리소스를 절약하는 것이다.

멀티스레드 환경에서 Thread-Safe하지 않으면 같은 객체를 여러 번 생성할 가능성이 생기고, 이는 메모리 낭비나 리소스 사용 증가로 이어질 수 있다.

 

Thread-Safe한 싱글톤 객체 생성 방법

1. 이른 초기화 Eager Initialization

클래스 로딩 시점에 객체를 생성해 간단하고 스레드에 안전하다.

public class Singleton {
    private static final Singleton instance = new Singleton();

    private Singleton() {
        // private constructor to prevent instantiation
    }

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

 

프로그램 실행 시, 클래스 로드에 의해 클래스가 로딩될 때 static 제어자에 의해 미리 인스턴스가 생성되는 방식

 

장점

구현이 매우 간딘하며, 클래스 로딩 시점에 인스턴스를 생성하므로 스레드 안전성이 보장된다.

단점

객체가 항상 생성된다. 사용하지 않을 경우 메모리 낭비가 있을 수 있다.

 

😮 멘토님을 통해 클래스 로드 시점을 고려해야 하면, 1번의 Eager Initialization 방법으로 구현하는 것과 5번의 정적 내부 클래스를 이용해 구현하는 것의 클래스 로드와 INSTANCE 생성 시점은 동일하다는 것을 알았다.(1번과 5번이 내부적으로는 똑같다는 거) 해당 내용 설명은 5번에서 하겠다.

 

2. Lazy Initialization

필요할 때 객체를 생성하는 방식. 단순하게 구현하면 멀티 스레드 환경에서 안전하지 않다. 

public class Singleton {
    private static Singleton instance;

    // private 생성자
    private Singleton() {
    }

    // 인스턴스 반환 메서드
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

 

• 단점 : 여러 스레드가 동시에 getInstacne()메소드를 호출하면 객체가 여러 번 생성될 수 있는 문제가 있다.

 

3. Synchronized를 사용한 Lazy Initialization

getInstance() 메소드를 synchronized로 만들어 여러 스레드가 동시에 접근하지 못하게 한다.

public class Singleton {
    private static Singleton instance;

    // private 생성자
    private Singleton() {
    }

    // 동기화된 인스턴스 반환 메서드
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

 

장점

스레드 안전성을 보장한다.

단점

getInstance() 메소드 호출 시마다 lock을 걸어 동기화를 수행하므로 성능이 저하될 수 있다.

 

4. Double-Checked Locking

synchronized로 인한 성능 저하를 줄이기 위해 고안된 방식이다. 인스턴스를 처음 생성할 때만 동기화를 수행한다.

public class Singleton {
    private static volatile Singleton instance;

    // private 생성자
    private Singleton() {
    }

    // 인스턴스 반환 메서드
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

 

volatile 키워드를 사용해 인스턴스를 volatile로 선언한 이유는, 인스턴스가 생성되는 과정을 다른 스레드가 잘못 참조하지 않도록 하기 위함이다. 인스턴스가 생성되는 동안 CPU 명령어가 최적화되어 중간 상태를 다른 스레드가 볼 수 있는 가능성을 방지한다.

• 관련 글 -> [Java] volatile 키워드 - 변수의 가시성, 재정렬 방지

• Double-Checked Locking 방식에서 volatile 키워드가 사용되는 이유는 객체의 생성 과정이 원자적이지 않기 때문이다. 객체를 생성하는 과정은 여러 단계(메모리 할당 -> 생성자 호출해 객체 초기화 -> 변수에 참조 할당)로 이루어지는데, 이 과정이 중간 상태일 떄에는 다른 스레드가 객체를 참조하면 완전히 초기화되지 않은 객체에 접근하는 문제가 발생할 수 있다. volatile 키워드를 사용하면 이 객체의 재정렬(명령화 최적화) 문제를 방지하고,  객체가 완전히 생성된 후에 다른 스레드에서 참조하도록 보장한다.

3번의 getInstance() 메소드에 추가한 synchronized를 빼면서 오버헤드는 줄인다.

 

null 체크를 두 번하는 이유 : 불필요한 동기화를 줄이고 성능을 최적하고 하기 위함. 싱그톤 객체가 이미 생성된 이후에는 동기화없이 빠르게 반환할 수 있다.

• 첫 번 째 null 체크의 역할
  • 불필요한 동기화 방지 : 첫 번째 if(instance == null) 체크는, 대부분의 경우 인스턴스가 이미 생성되어 있을 때 동기화 블록에 들어가지 않도록 하기 위한 것이다. 즉, 이미 싱글톤 객체가 생성된 상태에서는 여러 스레드가 동기화 블록에 접근하지 않게 해 성능 저하를 방지한다.
  • 싱글톤 객체가 이미 존재하는 경우, 이 조건문에서 빠르게 반환할 수 있으므로 동기화를 수행하지 않고도 빠른 접근이 가능하다.
• 두 번째 null 체크의 역할
  • 안전한 인스턴스 생성 보장 : 첫 번째 null 체크를 통과할 후, 동기화 블록에 들어갔을 때 다른 스레드가 이미 인스턴스를 생성했을 가능성을 방지하기 위한 것.
  • 예를 들어,
    1. 두 개의 스레드 A와 B가 동시에 첫 번째 null 체크를 통과했다고 가정하면,
    2. 두 스레드가 동기화 블록에 진입할 수 있다. 이때 스레드 A가 먼저 동기화 블록에 진입해 인스턴스를 생성하고
    3. 그 후 스레드 B도 동일한 블록 안에서 인스턴스를 생성하려 할 때, 두 번째 if(instance == null) 체크를 수행해 이미 생성된 인스턴스가 있으면 다시 생성하지 않도록 한다.

장점

인스턴스를 처음 생성할 때만 동기화를 사용하기 때문에 성능 이슈를 줄일 수 있다.

 

5. 정적 내부 클래스 Static Inner Class

Lazy Initialization을 보장하면서도, JVM의 클래스 로딩 원칙을 이용해 자연스럽게 스레드 안전성을 확보하는 방식이다.

public class Singleton {
    // private 생성자
    private Singleton() {
    }

    // 정적 내부 클래스
    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 인스턴스 반환 메서드
    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

 

장점

클래스 로딩 시점에 Singleton 클래스가 아닌 Holder 클래스가 로드되므로 Lazy Initialization을 지원하며, JVM 클래스 로딩 매커니즘을 이용해 스레드 안전성을 보장한다. 이 방식은 간결하면서도 성능 저하가 없는 것이 큰 장점이다.

 

내부 Static 클래스를 이용해 참조되기 전까지 내부 클래스를 로드하지 않는다.

Static final 인스턴스로 싱글턴 클래스가 선언되어, 인스턴스가 한 번만 초기화되고, 이후 접근 시 동일한 인스턴스가 반환되는 걸 보증한다.

• 이 방식이 Lazy Initialization을 지원하는 이유
  1. Lazy Loading 특성
     • Holder 클래스는 getInstance() 메소드가 호출될 때 최초로 로드된다. 이때 Holder 클래스가 로드되면서 그 안에 있는 INSTACE도 초기화된다.
     • Singleton 클래스 자체는 로드되더라도 내부의 Holder 클래스는 사용하지 않으면 로드되지 않으므로, INSTANCE는 필요할 때만 생성된다. 이렇게 Lazy Initialization이 자연스럽게 구현된다.
  2. JVM 클래스 로딩의 스레드 안전성
     • JVM은 클래스 로딩과 초기화 과정이 스레드 안전하도록 보장한다. 즉, 클래스가 로드되고 초기화되는 과정은 JVM에 의해 한 번만 이루어지며, 여러 스레드가 동시에 접근하더라도 문제가 발생하지 않는다.
     • 따라서 Holder 클래스가 로드될 때 INSTANCE가 초기화되면, 이 과정이 스레드 안전하기 때문에 추가적인 동기화 없이도 안전하게 싱글통 인스턴스를 생성할 수 있다.

 

라고 써놨으나, 클래스 로드 시점을 고려해보면, 1번과 5번으로 구현한 싱글톤 객체들은 getInstance()를 최초 호출 시에 내부적으로 동일하게 돌아간다.

• 관련 글 -> [Java] 클래스 로드

싱글톤 객체는 Singleton.getInstance() 코드를 한 묶음으로 호출해 사용한다. 클래스 로드 시점은 클래스가 처음 사용될 때이기 때문에, 두 방법으로 생성한 Singleton 객체들을 최초로 호출하는 Singleton.getInstance() 코드 사용시에 5번으로 구현된 정적 내부 클래스도 이 시점에서 로드된다. 5번의 장점이라는 Lazy Loading이 딱히 드러나지 않는다. 

 

6. Enum

자바의 enum은 기본적으로 싱글톤의 특성을 가지므로, 싱글톤 패턴 구현시 코드의 간결성, 직렬화 안전성, 그리고 멀티스레드 환경에서의 안전성을 모두 제공한다.

public enum Singleton {
    INSTANCE;

    // 원하는 메서드나 필드를 추가할 수 있습니다.
    public void someMethod() {
        System.out.println("Enum Singleton Method Called");
    }
}

 

INSTATNCE : 이 필드가 바로 싱글톤 객체이다. Singleton.INSTANCE를 호출하면 언제나 동일한 인스턴스를 반환한다.

enum은 JVM에서 클래스 로딩을 스레드 안전하게 보장하므로, 멀티스레드 환경에서도 안전한 싱글톤 객체를 제공한다.

 

장점 :

1. 구현이 간결하다.

2. 직렬화/역직렬화 과정에서 싱글톤의 유일성이 깨질 위험이 없다.

• enum의 직렬화/역직렬화 과정
  • JVM의 보장
    • enum 타입은 자바 언어 사양에 의해 고유하게 관리된다. 즉, 모든 enum 값은 JVM에 의해 단 하나의 인스턴스로 보장되며, 이를 통해 역직렬화 시에도 동일한 인스턴스가 반환된다.
    • 이는 enum이 클래스 로딩 시 자동으로 JVM 내에서 상수처럼 관리되기 떄문에 가능하다.
  • 직렬화의 특별 처리
    • enum은 자바에서 특별한 방식으로 직렬화되고, 역직렬화될 때도 그 유일한 인스턴스를 반환한다. 이는 java.io.Serializable 인터페이스의 일반적인 구현과는 다른 방식으로 처리된다.
    • enum은 역 직렬화 시 새로운 객체를 생성하지 않고, 항상 JVM에 저장된 싱글톤 인스턴스를 반환하므로, 유일성이 유지된다.
• 다른 싱글톤 객체에서 직렬화/역직렬화 과정의 문제
  
  • 다른 방식으로 구현한 싱글톤 객체는 기본적인 직렬화 방식을 사용하면 싱글토의 유일성이 깨질 수 있다. 그 이유는 다음과 같다.
    • 직렬화 과정
      • 일반 클래스의 경우, 싱글톤 객체를 직렬화하면 객체의 상태가 바이트 스트림으로 변환되어 저장된다.
    • 역직렬화 과정
      • 객체를 역직렬화하면, 저장된 바이트 스트림을 통해 새로운 객체 인스턴스가 생성된다. 이때 기존에 있던 싱글톤 객체가 아닌 새로운 객체가 만들어져서 싱글톤의 유일성이 깨질 수 있다.
  • 해결 방법 : readResolve()
    • 이러한 문제를 해결하기 위해, 일반적으로 readResolve 메소드를 구현해 싱글톤의 유일성을 유지한다. 이 메소드는 역질려화된 객체 대신 기존의 싱글톤 인스턴스를 반환하도록 한다.

private Object readResolve() throws ObjectStreamException {
    return instance; // 기존의 싱글톤 인스턴스를 반환
}

 

3. enum은 클래스 로딩 시점에서 JVM에 의해 초기화되며, 이 과정은 스레드 안전하므로 별도의 동기화 처리가 필요하지 않다.

• 클래스 로딩 시점의 동기화
  • JVM은 클래스 로딩 초기화를 클래스 로더 레벨에서 동기화해 처리한다. 즉, 클래스가 여러 스레드에 의해 동시에 로드될 수 있는 경우라도 JVM은 한 번에 하의 스레드만 클래스 로딩 및 초기화를 허용한다.
  • 이로 인해, enum 타입은 여러 스레드가 동시에 접근하더라도 초기화 과정에서 경합 상태나 데이터 일관성 문제가 발생하지 않는다.

4. enum은 리플렉션을 사용해도 새로운 인스턴스를 생성할 수 없어서 리플렉션 공격에 대한 방어가 가능하다.

• enum이 리플렉션을 통해 새로운 인스턴스를 생성할 수 없는 이유
  • 리플렉션을 통한 생성 제한 
    • enum의 생성자는 기본적으로 private이며, 자바 리플렉션 API를 통해 접근하더라도 새로운 인스턴스를 생성할 수 없게 되어 있다. enum 타입은 java.lang.reflect.Constructor의 newInstance() 메소드를 사용할 때, IllegalArgumentException을 발생시켜 새로운 인스턴스 생성을 막는다.
  • 자바 언어 스펙
    • enum은 상수처럼 사용되는 특별한 유형을 클래스이며, 이 특성을 유지하기 위해 리플렉션을 통한 인스턴스 생성이 제한된다. 이 설계는 enum 인스턴스가 항상 유일하며, 싱글톤의 특정이 유지되도록 보장하는 데 목적이 있다.
• 다른 방법으로 만든 싱글톤 객체에서 리플렉션 공격을 방어하는 방법
  • 기존 인스턴스가 있는 경우에 예외를 발생시킨다.
    • 리플렉션을 통한 생성 방지를 위해, 생성자 내부에서 기존 인스턴스 여부를 확인하고 이미 인스턴스가 존재한다면 예외를 던지는 방법이 있다. 이렇게 하면 리플렉션으로 생성자를 호출하더라도 기존 인스턴스가 있으면 새로운 인스턴스를 만들 수 없다.

public class Singleton {
    private static Singleton instance;

    // private 생성자
    private Singleton() {
        if (instance != null) {
            throw new RuntimeException("Use getInstance() method to create");
        }
    }

    // 인스턴스 반환 메서드
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

 

단점 : enum은 자바에서 클래스 상속을 지원하지 않아서 싱글톤 클래스를 상속해야 하는 경우에는 적합하지 않다. enum은 인스턴스 생성 방식이 고정적이라서, 초기화 과정에서 특정 파라미터를 받는 등 더 유연한 초기화를 원할 경우에 사용하기 어렵다.

 

안드로이드 환경에서는 어떤 방식이 적합할까?

1위. 정적 내부 클래스(Static Inner Class) 방식

 

🤔 왜 정적 내부 클래스(Static Inner Class) 방식으로 싱글턴 객체를 생성하는 것이 안드로이드 환경에서 더 적합할까?

1. 성능 최적화

정적 내부 클래스 방식은 클래스 로딩 시점에서 JVM에 의해 스레드 안전성을 보장받고, 동기화 블록이 필요하지 않아 불필요한 성능 저하를 피할 수 있다.

2. Lazy Initialization

인스턴스가 필요할 때까지 초기화되지 않아 메모리 자원을 효율적으로 사용한다. 이는 메모리 제약이 있는 안드로이드 환경에서 중요하다.

3. 안전성

JVM이 클래스 로딩과 초기화를 스레드 안전하게 처리하므로 멀티스레드 환경에서도 안전하게 싱글톤 인스턴스를 보장한다.

 

2위. Enum 방식

장점

• 구현의 간결성: enum은 간결하게 싱글톤을 구현할 수 잇으며, 추가적인 코드 없이 JVM이 스레드 안전성과 직렬화 안전성을 보장한다.
• 직렬과 안전성 : 안드로이드에서 직렬화된 객체를 복구할 때 enum 방식은 별도의 처리가 필요 없으며, 안전하다.
• 리플렉션 방어 :리플렉션을 통해 객체 생서이 불가능해, 다른 방법에 비해 더 안전하다.

단점

• 유연성 부족 : enum은 기본적으로 상속이 불가능하고, 파라미터를 통해 초기화해야 하는 경우에는 제한이 있다. Java의 특수한 방식이기 때문에 다른 JVM 언어나 특수한 초기화가 필요한 경우에는 사용이 어려울 수 있다.

⭐Double-Checked Locking + volatile 키워드 사용⭐

안드로이드에서는 싱글톤 생성시 Context를 파라미터로 가져와야 하는 경우들이 꽤 있다. getInstance()시 파라미터들을 받아올 수 없는 생성 패턴은 안드로이드에서 적합하지 않다.

또한 Double-Checked Locking은 성능도 좋다.

 

그러나 요즘에는 안드로이드에서 싱글톤 객체를 사용하지 않는다. 대신 Hilt를 사용한다.

 

(내용 추가 예정)