[디자인 패턴] 생성 패턴 - Singleton Pattern (싱글톤 패턴)

목차

 

 

📇 개요

싱글톤 패턴(Singleton Pattern)은 클래스의 인스턴스가 오직 하나만 생성되고, 어디서든 그 인스턴스에 접근할 수 있도록 하는 생성 디자인 패턴이다. 즉, 전역 변수를 사용하지 않고도 객체를 하나만 생성하여 어디서든 접근할 수 있게 하는 패턴이다.

 

⭐️ 특징

• 인스턴스가 오직 한 개만 존재하도록 보장한다.
• 전역적인 접근점을 제공하여 어디서든 동일한 인스턴스에 접근할 수 있다.
• 지연 초기화(lazy initialization)가 가능하여 필요한 시점에 인스턴스를 생성할 수 있다.

 

 

👩🏻‍💻 코드로 알아보자

싱글톤 패턴의 다양한 구현 방법을 살펴보자.

1. 기본 싱글톤 패턴

public class BasicSingleton {
    // 1. private static 변수로 유일한 인스턴스 선언
    private static BasicSingleton instance;
    
    // 2. private 생성자로 외부에서 인스턴스 생성 방지
    private BasicSingleton() {
        // 초기화 코드
    }
    
    // 3. public static 메서드로 인스턴스 접근점 제공
    public static BasicSingleton getInstance() {
        // 인스턴스가 없으면 생성 (지연 초기화)
        if (instance == null) {
            instance = new BasicSingleton();
        }
        return instance;
    }
    
    // 비즈니스 로직 메서드
    public void doSomething() {
        System.out.println("싱글톤 객체의 기능 수행");
    }
}

2. 스레드 안전한 싱글톤 (Thread-Safe Singleton)

public class ThreadSafeSingleton {
    private static ThreadSafeSingleton instance;
    
    private ThreadSafeSingleton() {
        // 초기화 코드
    }
    
    // synchronized 키워드로 스레드 안전성 보장
    public static synchronized ThreadSafeSingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeSingleton();
        }
        return instance;
    }
}

3. DCL(Double-Checked Locking) 싱글톤

public class DCLSingleton {
    // volatile 키워드로 변수의 가시성 보장
    private static volatile DCLSingleton instance;
    
    private DCLSingleton() {
        // 초기화 코드
    }
    
    public static DCLSingleton getInstance() {
        // 첫 번째 검사 (락 없이 빠른 체크)
        if (instance == null) {
            // 인스턴스화 부분에만 동기화 적용
            synchronized (DCLSingleton.class) {
                // 두 번째 검사 (락 획득 후 재확인)
                if (instance == null) {
                    instance = new DCLSingleton();
                }
            }
        }
        return instance;
    }
}

4. 초기화 온 디맨드 홀더(Initialization On Demand Holder) 패턴

public class InitOnDemandSingleton {
    private InitOnDemandSingleton() {
        // 초기화 코드
    }
    
    // 내부 static 클래스를 사용해 지연 초기화 구현
    private static class LazyHolder {
        // JVM이 클래스 로드 시점에 인스턴스 생성 (thread-safe)
        private static final InitOnDemandSingleton INSTANCE = new InitOnDemandSingleton();
    }
    
    public static InitOnDemandSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }
}

5. Enum 싱글톤

public enum EnumSingleton {
    INSTANCE; // 유일한 enum 상수가 싱글톤 인스턴스 역할
    
    // 비즈니스 로직
    public void doSomething() {
        System.out.println("Enum 싱글톤 기능 수행");
    }
}

// 사용 예
EnumSingleton singleton = EnumSingleton.INSTANCE;
singleton.doSomething();

6. 스프링 프레임워크에서의 싱글톤

import org.springframework.stereotype.Component;

@Component // 스프링 빈으로 등록
public class SpringSingleton {
    // 스프링이 알아서 싱글톤으로 관리
    public void doSomething() {
        System.out.println("스프링 싱글톤 빈의 기능 수행");
    }
}

// 사용 예
@Autowired
private SpringSingleton springSingleton;

 

☘️ 장/단점

✅ 장점

1. 메모리 효율성
   • 인스턴스가 오직 한 번만 생성되므로 메모리 사용량을 줄일 수 있다.
   • 특히 인스턴스 생성 비용이 큰 경우 효율적이다.
2. 전역 접근성
   • 어디서든 동일한 인스턴스에 쉽게 접근할 수 있다.
   • 여러 컴포넌트가 동일한 리소스나 서비스를 공유해야 할 때 유용하다.
3. 상태 공유
   • 애플리케이션 전체에서 동일한 상태를 공유할 수 있다.
   • 설정 관리, 캐싱, 리소스 풀링 등에 적합하다.
4. 인스턴스 제어
   • 인스턴스 생성을 엄격하게 제어할 수 있다.
   • 생성 시점과 방법을 정밀하게 관리할 수 있다.

❌ 단점

1. 단일 책임 원칙(SRP) 위반
   • 싱글톤 클래스는 자신의 인스턴스를 관리하면서 동시에 비즈니스 로직도 처리하므로 책임이 여러 개가 된다.
   • 이는 SOLID 원칙 중 SRP를 위반한다.
2. 테스트 어려움
   • 전역 상태를 가지므로 단위 테스트가 어려워질 수 있다.
   • 테스트 간에 상태가 공유되어 격리된 테스트가 어렵다.
3. 의존성 숨김
   • 클래스 간의 의존성이 명시적으로 드러나지 않는다.
   • 싱글톤을 사용하는 코드가 어디서든 접근할 수 있어 코드 추적이 어려워진다.
4. 다중 인스턴스 문제
   • 클래스 로더가 여러 개인 경우 의도치 않게 여러 인스턴스가 생성될 수 있다.
   • 직렬화/역직렬화 시에도 새로운 인스턴스가 생성될 수 있다.
5. 과도한 사용
   • 싱글톤 패턴을 남용하면 전역 상태에 의존하는 코드가 많아져 유지보수가 어려워질 수 있다.
   • 모듈 간 결합도가 높아져 코드 변경이 어려워진다.

 

💡 자바/스프링 프레임워크에서의 싱글톤

1. 스프링 컨테이너와 싱글톤

스프링 프레임워크는 기본적으로 빈(Bean)을 싱글톤으로 관리한다. 이는 스프링의 핵심 특징 중 하나이다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;

@Configuration
public class AppConfig {
    
    // 기본적으로 싱글톤 스코프를 가짐
    @Bean
    public UserService userService() {
        return new UserServiceImpl();
    }
    
    // 명시적으로 싱글톤 스코프 지정
    @Bean
    @Scope("singleton")
    public ProductService productService() {
        return new ProductServiceImpl();
    }
    
    // 프로토타입 스코프 (매번 새 인스턴스 생성)
    @Bean
    @Scope("prototype")
    public OrderService orderService() {
        return new OrderServiceImpl();
    }
}

2. 의존성 주입을 통한 싱글톤 사용

스프링에서는 싱글톤 빈에 대한 의존성을 주입받아 사용한다.

@Service
public class ProductServiceImpl implements ProductService {
    
    private final UserService userService;
    
    // 생성자 주입을 통해 싱글톤 빈 참조
    @Autowired
    public ProductServiceImpl(UserService userService) {
        this.userService = userService;
    }
    
    @Override
    public void processProduct() {
        // userService는 싱글톤 빈
        userService.getUserInfo();
    }
}

3. 싱글톤 빈 등록 방법

스프링에서 싱글톤 빈을 등록하는 여러 방법은 아래와 같다.

// 1. @Component 애노테이션 사용
@Component
public class LogManager {
    public void log(String message) {
        System.out.println("Log: " + message);
    }
}

// 2. @Service 애노테이션 사용 (서비스 레이어)
@Service
public class UserService {
    // 비즈니스 로직
}

// 3. @Repository 애노테이션 사용 (데이터 접근 레이어)
@Repository
public class UserRepository {
    // 데이터 접근 로직
}

// 4. @Controller 애노테이션 사용 (웹 레이어)
@Controller
public class UserController {
    // 웹 요청 처리 로직
}

// 5. @Configuration과 @Bean 사용
@Configuration
public class AppConfig {
    @Bean
    public EmailService emailService() {
        return new EmailServiceImpl();
    }
}

 

📚 실제 사용 사례

1. 로깅 시스템
   • 로그 인스턴스는 애플리케이션 전체에서 하나만 존재해야 함
   • 예: Java의 java.util.logging.Logger
2. 데이터베이스 연결 풀
   • DB 연결과 같은 비용이 큰 리소스를 효율적으로 관리
   • 예: 커넥션 풀 라이브러리(HikariCP, DBCP 등)
3. 설정 관리
   • 애플리케이션 설정을 중앙에서 관리
   • 예: 프로퍼티 관리자, 환경 설정 매니저
4. 캐시 구현
   • 애플리케이션 전체에서 동일한 캐시 인스턴스에 접근
   • 예: 메모리 캐시, 분산 캐시의 클라이언트
5. 스레드 풀
   • 제한된 수의 스레드를 효율적으로 관리
   • 예: Java의 ExecutorService 구현체
6. 디바이스 관리자
   • 프린터, 스캐너 등 하드웨어 장치와의 통신 관리
   • 예: 프린터 스풀러, 디바이스 드라이버 인터페이스
7. UI 구성요소 관리
   • 대화상자, 스플래시 화면 등 UI 요소 관리
   • 예: JavaFX의 Stage 관리, Android의 ActivityManager
8. 스프링 빈
   • 스프링 프레임워크에서 기본적으로 모든 빈은 싱글톤으로 관리됨
   • 예: Service, Repository, Controller 등의 빈
9. 파일 시스템 접근
   • 파일 시스템에 대한 접근을 중앙에서 관리
   • 예: 파일 매니저, I/O 유틸리티
10. 네트워크 관리
    • 네트워크 연결 및 소켓 관리
    • 예: HTTP 클라이언트, 소켓 서버

 

📌 정리

싱글톤 패턴은 인스턴스를 오직 하나만 생성하고 전역적으로 접근할 수 있게 하는 디자인 패턴이다.

이 패턴은 애플리케이션에서 공유 리소스나 서비스에 효율적으로 접근해야 할 때 유용하지만, 과도한 사용은 코드의 결합도를 높이고 테스트를 어렵게 만들 수 있다. 따라서 필요한 경우에만 신중하게 사용해야 한다.

✅ 언제 사용하면 좋을까?

• 공유 리소스에 대한 접근 관리가 필요할 때(DB 연결 풀, 스레드 풀 등)
• 전역적으로 유일한 설정이나 상태를 관리해야 할 때
• 리소스 생성 비용이 큰 객체를 여러 번 생성하지 않아야 할 때
• 여러 컴포넌트가 동일한 인스턴스에 접근해야 할 때

❌ 언제 피해야 할까?

• 객체 지향 설계 원칙을 엄격히 준수해야 할 때
• 단위 테스트가 중요한 경우
• 상태를 공유하지 않는 것이 더 적합한 경우
• 인스턴스 생성을 제어할 필요가 없는 경우

 

 

 

📋 참고

• https://refactoring.guru/ko/design-patterns/singleton