[Spring] 싱글톤 패턴

해당 글은 김영한님의 스프링 핵심 원리 강좌를 정리한 글 입니다.

Spring은 기업용 온라인 서비스 기술을 지원하기 위해서 만들어졌고, 대부분의 스프링 어플리케이션은 웹이다.

 

웹은 주로 여러 개의 클라이언트로부터의 요청이 동시에 발생하게 되고, 요청이 올 때 마다 객체를 생성하게 되는 데 고객 트래픽이 1초에 100이라면 1초에 100개의 객체가 생성 되는 심각한 메모리 낭비가 발생하게 되었다.

 

해당 문제를 해결 하기 위해서 하나의 객체를 생성하고, 이 객체를 공유하도록 설계를 하여 효율적인 개발을 하게 되는 데 이를 싱글톤 패턴이라고 한다.

 

 

싱글톤 패턴

싱글톤 패턴은 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.

그러기에 객체 인스턴스를 2개 이상 생성하지 못 하도록 막아야하며, private 생성자를 사용하여 외부에서 임의로 new 키워드를 사용하지 못 하도록 막게된다.

 

싱글톤은 메모리 낭비를 막는다는 장점이 있지만 단점도 많이 존재한다.

• 싱글톤 패턴을 구현하는 코드가 많이 들어간다.
• 의존 관계상 클라이언트가 구체 클래스에 의존하여 DIP를 위반하게 된다.
• 클라이언트가 구체 클래스를 의존하기에, OCP 원칙을 위반할 가능성이 높다.
• 테스트 하기 어렵다.
• 내부 속성을 변경하거나 초기화하기 얼렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어진다.
• 안티패턴이라고 불리기도 한다.

 

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리하여, 싱글톤 컨테이너 역할을 하게 된다. 이렇게 싱글톤을 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

 

스프링 컨테이너 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지해 메모리 낭비를 막을 수 있으며, 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 되고, DIP, OCP, 테스트, privite 생성자등으로부터 자유롭게 싱글톤을 사용할 수 있다.

 

 

싱글톤 방식의 주의점

싱글톤 방식은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기에, statefull(상태 유지)로 설계하면 안 되기에, stateless(무 상태)로 설계를 해야한다.

 

특정 클라이언트에 의존하는 필드가 있으면 안 되고, 클라이언트가 필드를 수정할 수 있으면 안 된다.

가급적 읽기만 가능해야하며, 필드 대신에 지역 변수, 파라미터 등을 사용하자.

 

만약 statefull로 설계를 하면, 싱글톤 하나의 객체를 공유하는 데, 객체의 필드 값이 이상하게 수정되어 큰 에러를 발생시킬 수 있다.