[Spring] 싱글톤 패턴

클라이언트가 요청할 때 마다 새로운 인스턴스가 생긴다. 이것은 서버에 많은 비용을 요구한다. 정말로 클라이언트의 요청마다 새로운 인스턴스가 생성이 되는지 확인을 해보겠다.

 

참조값을 확인하면 서로 다른 인스턴스인 것을 알 수 있다.

• 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다.
• 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다. -➡️ 메모리 낭비가 심하다.
• 💡해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. ➡️ 싱글톤 패턴

 

싱글톤 패턴

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
• 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
  • private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.

 

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
2. 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

1. private으로 new 키워드를 막아두었다.
2. 호출할 때 마다 같은 객체 인스턴스를 반환하는 것을 확인할 수 있다.

Singleton 을 적용한 후 이제는 새로운 인스턴스를 만들지 않는다는 것을 확인할 수 있다.

 

💡참고: 싱글톤 패턴을 구현하는 방법은 여러가지가 있다. 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했다.

싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 다음과 같은 수 많은 문제점들을 가지고 있다.

 

싱글톤 패턴 문제점

싱글톤은 생성된 인스턴스를 공유를 할 수 있고 확실한 객체 하나가 있다는 것이 보장이 되지만 수많은 단점이 있다.

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. ➡️ DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다. (싱글톤은 지정해서 가져오고 미리 인스턴스를 받아놓아서 설정이 끝나버리기 때문에 유연한 테스트가 어렵다.)
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다. (DI 를 적용하기 어렵다.)
• 안티패턴으로 불리기도 한다.

이러한 단점을 스프링 프레임워크가 전부 다 해결해준다. ➡️ 객체를 싱글톤으로 관리해준다. 

 

다음은 스프링 컨테이너(싱글톤 컨테이너) 의 역할에 대해서 알아보자.

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

[Spring] 싱글톤 컨테이너