🔮 특징/목적 4~5 min read
📜 코드/동시성 8 min read

---

🌟 싱글톤 패턴이란?

싱글톤 패턴의 이름에서 알 수 있듯이, 이 패턴은 '하나$_{Single의\ 명사화}$'와 관련이 깊습니다.
이 패턴은 객체를 하나만 만들어서 이를 재사용하는 패턴입니다.

우리는 이 패턴을 설명하는 과정에서 '유일 객체'를 '싱글톤'이라 부를 수 있습니다.

전산 인력이 한 명뿐인 회사의 풍경과도 닮았습니다.

💡 왜 싱글톤 패턴을 사용할까?

(장) 객체 생성 비용의 절감
싱글톤 패턴을 사용하면, 곳곳에서 매번 객체를 생성하는 비용을 들일 필요가 없습니다.
그런데 이건 사실 싱글톤이라서 얻는 장점은 아니고, 객체를 미리 만들었기 때문에 얻는 장점입니다.

뒤따르는 장점으로 로직 곳곳에서 객체 생성에 의한 메모리 낭비를 줄일 수 있습니다. 이는 객체 생성 후 메모리를 해제하는 비용을 절감에도 영향을 줍니다. 즉, (매번 객체를 생성할 때보다) 메모리도 아끼면서 조금 더 빠른 동작을 얻을 수 있습니다.

(장) 유일 객체의 보장과 공유
그 외 장점으로는 유일 객체이기 때문에 공유하기에 용이한 객체이기도 합니다. 이 객체가 저 객체인지 걱정할 것 없이, 이 루틴에서도 저 루틴에서도 동일한 객체를 사용하고 있겠죠.

(단) 유일 객체의 공유
이는 동시에 단점이 될 수 있는데 이 객체의 자원이 무분별하게 곳곳에서 변경될 여지가 있다면 서로 다른 루틴에서 영향을 받을 여지가 있습니다. 그런데 이럴 땐 알맞게 사용하면 해결됩니다(잘못 사용한 경우가 문제라는 것).

무분별하게 사용하지 않기
그래서 무분별하게 싱글톤을 택하는 경우는 잘 없고, 변경 가능한 내부 필드보다는 불변성 필드와 동작(메서드) 위주로 제공하는 객체로 사용하기에는 무리가 덜한 편입니다. (스프링에서 기능을 제공하는 서비스 객체 등)

(단) 생성 시 지연 로딩 및 동시성을 보장하는 데에 주의가 필요함.
추가적인 단점으로는 생성에 있어서 주의가 필요하다는 점 정도인데, 오늘 이 글에선 이 문제를 자바에서 어떻게 해결하면 되는지 다룹니다.

PS. 스프링에서는 ✍️

만약 우리가 스프링을 사용하고 있다면, 스프링의 주요 컨테이너(IoC 컨테이너)는 기본적으로 우리가 사용할 의존성 객체 Bean들을 싱글톤 객체로 취급합니다.

물론 우리가 이 클래스를 작성할 때 생성자를 직접적으로 막은 것은 아니기 때문에, 추가적으로 인스턴스를 생성해서 로직에 사용할 순 있습니다만, 이 경우 스프링이 이 객체를 자동으로 Bean으로 취급하진 않을 것입니다.

(생성자를 막은 것은 아니기 때문에 온전히 싱글톤 패턴을 적용한 것은 아니고, 싱글톤 컨테이너를 생성해 취급한 것입니다.)

왜 모든 것을 static으로 사용하지 않고 싱글톤 객체를 만들어서 쓸까?

그런데 객체를 하나만 만들어서 그 객체를 통해 클래스의 온갖 기능을 사용한다는 설명에서 한 가지 의문을 생각해 볼 수 있습니다.

이 클래스의 모든 멤버 변수와 메서드를 static으로 취급하면 동일한 것 아닐까?

이러한 의문입니다. 그럼에도 불구하고 static을 삼가는 것은 static의 여러 약점 때문이죠.

static은 언제 어디에서 어떻게 변경될지 모르는(final이 아니라면) 데이터가 됨과 동시에 생명주기가 의도에 비해 길 수밖에 없습니다. 이러한 특성은 컴파일러의 최적화 전략에도 혼란을 심어줄 수 있죠. 따라서 static은 static final을 사용할 때를 제외하면 일반적으로 꼭 필요한 패턴이 아닐 땐 삼가는 것이 좋을 수 있습니다.

자세한 설명은 본 글의 취지에 비해 설명이 길 수 있기 때문에 이번 단락은 생략합니다. 자세한 내용이 궁금한 분들은, 싱글톤에서 static을 삼가는 이유를 떠나서, 코드 작성 시 개발자가 static 사용을 삼가는 이유 위주로 조사해 보실 수 있습니다.

---

싱글톤 패턴 레시피

개념을 설명하기 위한 간단한 구현 🍰

싱글톤 패턴의 기본적인 설명을 위한 코드입니다.

• 다른 곳에서 객체를 생성할 수 없도록 생성자의 공개 범위를 좁힙니다.
• 싱글톤 객체를 클래스 내부에 하나 생성합니다(static).
• 싱글톤 객체를 제공하는 메서드를 하나 둡니다(static).

그러면 이 객체는 이 클래스에 있는 여러 속성과 기능을 non-static으로 제공합니다.

public class MyExample {
    // [1] 싱글톤 객체를 여기에서 하나 만듭니다.
    private static final MyExample INSTANCE = new MyExample();
    
    // [2] (핵심) 다른 곳에서 객체를 생성할 수 없도록 private 생성자!
    private MyExample() {}

    // [3] 인스턴스를 제공하는 정적(static) 메서드를 제공합니다.
    public static MyExample getInstance() {
        return INSTANCE;
    }
    
    // (이제 다른 기능을 작성합니다.)
}

그러나 이 방식은 클래스만 사용하는 시점에도 인스턴스를 초기화해 메모리에 올리게 됩니다.
자바는 클래스를 런타임 메모리에 올릴 때(= 클래스 로드 타임), 그 클래스의 static 필드도 초기화해서 메모리에 올리기 때문입니다.

우리는 '이 객체를 사용하는 시점'에 메모리에 올리고 싶습니다.

⏱ 지연 로딩

그래서 우리는 지연로딩을 생각합니다.
다음 코드는 이 객체를 실제 사용하는 시점에 객체 생성을 수행하도록 변경합니다.

public class MyExample {
    // [1] 싱글톤 객체를 아직 안 만듭니다. 이때 null로 초기화되는 자바 특징이 있습니다.
    private static MyExample INSTANCE; // (final을 사용하지 않습니다.)
    
    private MyExample() {}

    public static MyExample getInstance() {
        // [2] null인 경우에만 객체를 생성해서 담습니다.
        if (INSTANCE == null) {
            INSTANCE = new MyExample(); // 이제 INSTANCE는 null이 아닙니다.
        }
        
        // 객체를 믿고 반환할 수 있게 되겠죠. 아마도요?
        return INSTANCE;
    }
}

🎾 + 🎾 싱글톤 생성의 동시성 문제

위 코드에서는 getInstance() 메서드를 처음으로 사용할 때 싱글톤 객체를 생성하고 있습니다. 아무런 문제가 없어 보였지만, 만약 두 명 이상의 사용자가 비슷한 요청을 보내서 각 루틴이 동시에 싱글톤 객체를 생성하려 했다면 어떨까요?

사용자의 각 요청은 각각의 스레드에서 처리된다는 것을 생각하며 다음 흐름을 살펴봅시다.

⬇️ 둘 이상의 스레드가 비어 있는 싱글톤 자리를 발견합니다.

⬇️ 둘 이상의 스레드가 싱글톤 객체를 각자 생성하여 사용하였습니다.

⬆ 이 과정에서 이미 더 이상 '싱글톤'이 아닌 객체가 하나는 존재했을 것입니다.

이것이 싱글톤 객체 등을 생성할 때 발생할 수 있는 '동시성 문제'${}$입니다.
다행히 자바에서는 이런 문제를 대처할 수 있는 여러 수단이 있는데, 아래 코드에서 설명하겠습니다.

스레드 세이프 (1): synchronized method

아주 무식한 해결 방식입니다.
그냥 객체를 받는 행위 자체를 스레드들이 한 스레드씩 줄을 서서 천천히 받아가게 하는 겁니다.

public class MyExample {
    private static MyExample INSTANCE;
    
    private MyExample() {}

    // synchronized 수식어를 통해, 이 메서드는 동시에 하나의 스레드만 사용할 수 있습니다.
    public static synchronized MyExample getInstance() {
        if (INSTANCE == null) {
            // 여기에 둘 이상의 스레드가 들어올 수 없기 때문에 하나의 객체임을 보장합니다.
            INSTANCE = new MyExample();
        }
        
        // 이번엔 정말로 객체를 믿고 반환할 수 있게 됩니다.
        return INSTANCE;
    }
}

간단한 키워드 하나를 추가해서 싱글톤 객체의 동시 생성은 막을 수 있었는데, 동시에 사용될 수 없는 메서드를 추가함으로써 엄청난 성능 저하가 될 수 있습니다. 100만 명의 사용자가 동시에 비슷한 요청을 보냈다면 어떨까요? 동시에 처리할 수 있었던 일도 모두 이 과정을 기다리며 처리해야 했을 것입니다.

스레드 세이프 (2): double-checked synchronized

적어도 위와 같은 문제를 막기 위해서는 어떡할까요?
이미 INSTANCE가 싱글톤 객체로 초기화되어 있을 때는 여러 스레드의 동시 접속을 허락해도 될 것입니다.

public class MyExample {
    private static MyExample INSTANCE;
    
    private MyExample() {}

    public static MyExample getInstance() {
        if (INSTANCE == null) {
            // [A] 여기까진 아까처럼 동시에 둘 이상의 스레드가 들어올 때도 있을 수 있습니다.
            synchronized (INSTANCE) { // 이 자원에 대해서 순차적으로 접근하게 하고
                // 그럼에도 [A] 구간에서 다른 스레드가 기다리고 있을 수 있으니까
                if (INSTANCE == null) { // 여기서 한 번 더 체크해서
                    INSTANCE = new MyExample(); // 진짜 유일한 객체를 만듭니다.
                }
            }
        }
        // 위 if문 블럭은 INSTANCE가 `null`이 아닐 때,
        // `synchronized () {...}` 블럭을 생략할 수 있게 합니다.
        
        // 객체를 믿고 반환할 수 있게 됩니다. 그것도 동시에 여러 스레드가 사용할 수 있고요.
        return INSTANCE;
    }
}

• 바깥쪽 if문: 이미 객체가 생성되어 있다면, 더 이상 synchronized 블럭에 진입할 필요가 없게 합니다. 따라서 여러 스레드가 동시에 이 메서드를 사용할 수 있도록 합니다.

• 안쪽 if문: 바깥쪽 if문은 동시성을 보장하기 위한 것이 아니었습니다. 따라서 안쪽 if문 입구에는 동시에 바깥쪽 if문을 통과했던 다른 스레드가 다음 차례에 다가올 수도 있습니다. 즉 둘 이상의 스레드가 synchronized 블럭에 차례로 하나씩 진입할 순 있습니다. 따라서 먼저 방문한 스레드가 이미 객체를 생성했을 때 다음에 온 스레드는 객체를 새로 생성할 수 없도록 안쪽 if문으로 막아 둔 것입니다.

스레드 세이프 (3): 클래스 로드 타임

우리가 싱글톤 패턴을 처음 설명할 때 위에서 봤던 코드를 기억하시나요?
그 코드가 비록 '지연 로딩'이라는 이점은 없더라도, 이미 '스레드 세이프'를 보장하고는 있습니다.

이것을 제가 어떻게 알까요?
사실 그냥, 자바가 그렇게 설명하고 있기 때문입니다.

자바는 클래스를 메모리에 올리는 '클래스 로드 타임'에는 동시성을 보장해 줍니다.
즉, 우리가 너무 고생할 필요 없이 이 '클래스 로드 타임'을 이용하면 되는 겁니다.

그런데 우리가 원하는 것은 '지연(lazy) 로딩'과 '스레드 세이프(thread-safe)' 모두입니다.
따라서 '인스턴스가 처음 사용될 때 메모리에 처음 로드되는 클래스'가 있다면 아무 걱정 없었을 것이란 말이죠.

// 코드는 관례를 무시하고 설명 순서에 맞추었습니다.
public class MyExample {
    // [1] 이제 인스턴스는 여기 없습니다.
    
    // [2] 그냥 생성자나 막아 둡시다. (얘는 항상 싱글톤 패턴의 핵심입니다.)
    private MyExample() {}

    // [3] 내부 클래스는 위 private 생성자도 사용할 수 있습니다.
    private static class Holder {
        // 이제 이곳에 인스턴스를 작성하면 됩니다.
        private static final MyExample INSTANCE = new MyExample();
    }
    
    // [4] 그래도 목적이 되는 탑레벨 클래스가 인스턴스를 제공하긴 해야 하죠.
    public static MyExample getInstance() {
        // Holder 클래스는 이렇게 인스턴스를 제공할 때 말곤 안 쓰이니까,
        // 아래 코드에 의해서 (처음 사용될 때) 메모리에 올라갑니다.
        return Holder.INSTANCE; // 이때 말곤 미리 생성될 일 없는 거죠.
    }
}

🛹 메모리에 올라가는 시점

• INSTANCE는 Holder라는 클래스가 메모리에 올라갈 때 초기화됩니다.
• 그리고 Holder라는 클래스는 getInstance()라는 메서드가 처음 호출될 때 메모리에 올라갑니다.

그것이 자바의 특징이거든요. 많이들 클래스가 import 될 때 메모리에 올라간다고 오해하는데, 실제로는 실질적으로 처음 사용할 때 메모리에 올라갑니다.

이로써 이 Holder라는 내부 클래스가 다음 두 특성을 모두 보장해 줍니다. 그냥 자신이 클래스라는 이유만으로요. 그것이 자바이니까.

• Lazy
• Thread-safe

Holder가 메모리에 올라가면서 INSTANCE를 생성하니까.

---

🚕 결론

마지막 거 쓰세요. 🚕 🚕 🚕 ~

• 순서 정리한 코드:

  public class MyExample {
  
      // [1] 생성자 private
      private MyExample() {}
  
      public static MyExample getInstance() {
          // [2] 객체 제공(내부 클래스 거)
          return Holder.INSTANCE;
      }
  
      // [3] 싱글톤 객체 담는 클래스 (클래스 로드 타임 활용)
      private static class Holder {
          private static final MyExample INSTANCE = new MyExample();
      }
  }