Spring - Singleton

싱글톤 패턴이란?

최초 생성 시에만 객체를 생성하고, 그 이후로는 이미 생성해 둔 객체를 return하게끔 하여, 프로그램 상에서 싱글톤 객체가 딱 하나만 존재하도록 막는 것이다. 

 

웹 애플리케이션과 싱글톤

지금까지는 Spring의 기능을 사용하지 않고, AppConfig를 직접 구현해서 사용했다.

지금의 DI 컨테이너는 new 연산을 통해 객체를 return하고 있다. [return new MemberRepository()]

이는 클라이언트의 요청이 올 때마다 객체를 생성하는 것을 의미한다. 

요청이 들어올 때 마다 객체를 생성한다면 1초 당 요청이 100개가 올 때, 100개 이상의 객체가 생성되고 소멸하게 된다. 

이는 심각한 메모리 낭비를 초래하기 때문에 객체 생성이 불필요한 서비스 같은 객체는 딱 하나만 생성하고 이를 공유해서 사용하는 싱글톤 패턴의 적용이 필요하다. 

 

하지만, 싱글톤 패턴에도 역시 단점이 있다.

클라이언트가 구체 클래스에 의존한다. -> DIP를 위반하며, OCP를 위반할 가능성이 높다.

유연성이 떨어진다 -> 구체 클래스에 getInstance를 통해 객체를 받아야 하기 때문이다. 이 코드는 고정되어 절대 바뀔 수 없을 뿐더러 싱글톤 패턴의 모든 클래스가 필수적으로 가지게 된다.

테스트가 어렵다 -> 내부 속성을 변경하거나 초기화하기 어렵다. 또한 생성자를 private로 막아 두기 때문에 자식 클래스를 만들기 어렵다. 

 

싱글톤 컨테이너

싱글톤의 단점을 전부 커버한다. 

스프링 빈이 싱글톤으로 관리되는 빈이다. (클래스의 인스턴스가 아닌 '스프링 빈'이)

스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 하나만 사용할 수 있다. 

이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 기본 설정은 싱글톤이지만, 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 있다. 

 

싱글톤 방식의 주의점

여러 클라이언트가 하나의 객체를 공유하여 사용하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계해서는 안된다. 무상태(stateless)로 설계해야 한다.

특정 클라이언트에 의존적인 field가 있으면 안된다.

특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.

가급적 읽기만 가능해야 한다.

스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 일어날 수 있다. 

되도록이면 다른 객체들이 함께 공유해서 사용할 수 있는 공유변수는 사용하지 않아야 한다.

EX) 물건 값을 공유변수인 price에 저장하기 보다는, 클래스의 지역변수로 price를 선언하여 유저A, 유저B가 각각 price라는 지역변수를 갖게 한다.