2.17 싱글톤 공부

• 메모리 절약을 위해, 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용하는 기법
• 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합

장점

• 클래스가 하나의 인스턴트만 갖는다는 것을 확신할 수 있습니다.
  • 여러 개의 인스턴스를 생성할 필요가 없으므로 메모리 낭비를 방지함
• 이 인스턴스에 대한 전역 접근 지점을 얻습니다.
  • 새로운 객체를 계속 만들 필요 없이 하나의 인스턴스를 공유하므로 메모리 사용량을 줄일 수 있음
• 싱글턴 객체는 처음 요청될 때만 초기화됩니다. 
  • 필요할 때만 객체가 생성되므로, 불필요한 메모리 사용을 방지

단점

• 단일 책임 원칙을 위반합니다. 이 패턴은 한 번에 두 가지의 문제를 동시에 해결합니다.
  • 객체 관리와 로직 처리를 동시에 하기 때문에
• 이 패턴은 다중 스레드 환경에서 여러 스레드가 싱글턴 객체를 여러 번 생성하지 않도록 특별한 처리가 필요합니다.
  • ex) synchronized 키워드 사용
• 싱글턴의 클라이언트 코드를 유닛 테스트하기 어려울 수 있습니다.
  • 그 이유는 많은 테스트 프레임워크들이 모의 객체들을 생성할 때 상속에 의존하기 때문입니다.
  • 싱글턴 클래스의 생성자는 비공개이고 대부분 언어에서 정적 메서드를 오버라이딩하는 것이 불가능하므로 싱글턴의 한계를 극복할 수 있는 창의적인 방법을 생각해야 합니다. 아니면 그냥 테스트를 작성하지 말거나 싱글턴 패턴을 사용하지 않으면 됩니다

싱글톤 레지스트리

• private 생성자를 사용해야 하는 방법이 아닌 평범한 자바 클래스를 싱글톤으로 활용할 수 있게 해준다.
• IoC 방식의 컨테이너를 사용해서 생성과 관계설정, 사용 등에 대한 제어권을 컨테이너에게 넘기면서 손쉽게 싱글톤 방식으로 관리되게 할 수 있다.
  • 오브젝트 생성에 관한 모든 권한은 IoC 기능을 제공하는 애플리케이션 컨텍스트에 있기 때문이다.

아래는 chat gpt에서 발췌한 글입니다.

싱글톤 레지스트리의 잠재적 문제점

1.  의도치 않은 상태 공유 (Stateful Bean 문제)

• 스프링이 빈을 싱글톤으로 관리하다 보니,빈이 상태를 가지면(필드 값 변경) 여러 쓰레드에서 공유 문제가 발생할 수 있음.
• 즉, 스프링의 빈은 기본적으로 "무상태(Stateless)"로 설계하는 게 안전함!

해결 방법

• 상태를 유지해야 하는 경우, 싱글톤 빈을 사용하지 말고 @Scope("prototype")을 고려.
• 또는 각 요청마다 새로운 객체를 생성하는 방식(Request, Session 스코프 등)도 가능.

---

2. 동일한 빈을 다른 의존성 주입 방식과 혼용할 때 발생하는 문제

• 만약 싱글톤 빈이 내부적으로 프로토타입 빈을 주입받아야 하는 상황이면,싱글톤 빈이 생성될 때 단 한 번만 프로토타입 빈이 주입됨!
• 즉, 매번 새로운 프로토타입 빈을 기대했지만, 실제로는 같은 인스턴스를 사용하게 되는 문제 발생!

 해결 방법

• @Scope("prototype")을 사용할 경우,프록시(proxy) 방식이나 ObjectProvider를 활용하여 필요할 때마다 새로운 빈을 요청하도록 변경!

 

의문점.. 무상태 설계란 무엇인가??