[CS] 자바 디자인 패턴 - 싱글턴 패턴(Singleton pattern)

개요

- 디자인패턴이란?

객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용하는 패

디자인 패턴은 모듈의 세분화된 역할이나 모듈들 간의 인터페이스 구현 방식을 설계할때 참조할 수 있는 전형적인 해결 방식을 말한다. 디자인 패턴을 통해 설계 문제, 해결 방법, 해결 방법을 언제 적용해야 할지, 그 결과는 무엇인지 등을 알 수 있다. 또한 디자인 패턴은 한 패턴에 변형을 가하거나 어떠한 요구사항을 반영하면 다른 패턴으로 변형되는 특징이 있다.
1995년 GoF(Gang of Four)라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vissides가 처음으로 디자인 패턴을 구체화하였다. GoF의 디자인 패턴은 소프트웨어 공학에서 가장 많이 사용되는 디자인 패턴이다. 목적에 따라 분류할 시 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개, 총 23개의 패턴으로 구성된다.

 

싱글톤 패턴(Singleton pattern)

소프트웨어 디자인 패턴에서 싱글톤 패턴(Singleton pattern)을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다. 이와 같은 디자인 유형을 싱글톤 패턴이라고 한다. 주로 공통된 객체를 여러개 생성해서 사용하는 DBCP(DataBase Connection Pool)와 같은 상황에서 많이 사용된다.

즉, 싱글톤 패턴은 다음과 같은 상황에 사용을 한다.

- 프로그램 내에서 하나의 객체만 존재해야 한다.

- 프로그램 내에서 여러 부분에서 해당 객체를 공유하여 사용해야한다.

 

싱글톤 패턴을 사용하는 이유 - 장점

1. 메모리 측면의 이점

싱글톤 패턴을 사용하게 된다면 한개의 인스턴스만을 고정 메모리 영역에 생성하고, 추후 해당 객체를 접근할 때 메모리 낭비를 방지할 수 있다.

 

2. 속도 측면의 이점

생성된 인스턴스를 사용할 때는 이미 생성된 인스턴스를 활요하여 속도 측면에 이점이 있다.

 

3. 데이터 공유가 쉽다.

전역으로 사용하는 인스턴스이기 대문에 다른 여러 클래스에서 데이터를 공유하며 사용할 수 있다. 하지만 동시성 문제(데이터 정합성)가 발생할수 있어 이 점을 유의해야 한다.

 

싱글톤 패턴의 문제점 - 단점

1. 의존성문제

싱글톤 패턴은 클래스의 객체를 미리 생성한 뒤에 필요한 경우 정적 메서드를 이용하기 때문에, 클래스 사이의 의존성이 높아지게 된다는 문제점이 있다. ( 높은 결합 ) 싱글톤의 인스턴스가 변경되면 해당 인스턴스를 참조하는 모든 클래스들을 수정해야 하는 문제가 발생한다.

 

2. private 생성자 때문에 상속이 어렵다.

싱글톤 패턴은 기본 생성자를 private로 만들었기 때문에, 상속을 통한자식 클래스를 만들 수 없다는 문제점이 있다. 즉 자바 객체지향 언어의 장점 중 하나인 다형성을 적용하지 못한다는 문제로 이어진다. 

 

 

 

Spring - 싱글톤 컨테이너(스프링 컨테이너)

 

스프링 컨테이너 개념도

 

Spring Framework에서 빈(Bean)을 관리하는 기본적인 방식은 싱글톤 패턴과 관련이 있다. Spring은 기본적으로 빈을 싱글톤으로 관리하며, 한 개의 인스턴스를 생성하고 모든 요청에 대해 동일한 인스턴스를 반환한다.
스프링 프레임워크에서는 빈(Bean)을 관리할 때 주로 싱글톤 패턴을 사용하는데 이유는 다음과 같다.

 

- 성능 및 자원 관리

빈이 Singleton으로 관리되면 메모리와 자원을 효율적으로 사용할 수 있다. 매번 새로운 인스턴스를 만드는 비용을 줄이고, 중요한 리소스를 공유할 수 있기 때문이다.

- 일관성과 데이터 공유

같은 인스턴스가 여러 컴포넌트에 공유되니, 데이터의 일관성을 유지하기 쉽다. 설정 정보나 데이터베이스 연결 같은 중요한 자원을 효과적으로 관리할 수 있다.

- 의존성 주입의 편의

Singleton 빈은 의존성 주입을 통해 다른 컴포넌트에 쉽게 주입될 수 있다. 모든 컴포넌트가 동일한 인스턴스를 사용하면 의존성 관리가 수월해진다.

 

스프링에서는 개발자가 직접 싱글톤을 구현하거나 인스턴스를 관리할 필요가 없다. 스프링 컨테이너가 이 모든 걸 해주기 때문이다. 그리고 Singleton만 있는 게 아니라, Prototype, Request, Session 같은 다른 스코프도 지원해서 더 다양한 요구사항에 맞게 인스턴스를 관리할 수 있다.