싱글톤 패턴

왜 싱글톤?

-(기존) 클라이언트가 요청할때마다 객체가 생성 -> 메모리 낭비

-해결책: 해당 객체를 한개만 생성하고 공유하도록 설계

-클래스의 인스턴스가 딱 1개만 생성되는것을 보장하는 디자인 패턴

-e.g. static 영역에 객체 instace를 미리하나 생성하고 getInstance()메서드를 통해서만 조회

-생성자를 private 막아서 new 키워드로 객체 인스터스가 생성되는것을 막음

-하나의 객체만을 쓰기 때문에 시스템 효율증가

 

-단점

    - DIP 위반(클라이언트가 구체 클래스에 의존) e.g. 구체클래스.메서드()

    - OCP 위반

    - 테스트하기 어려움(설정이 이미 끝남)

    - 유연성이 떨어짐

 

싱글톤 컨테이너

-싱글톤 패턴의 모든 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리(스프링 빈 객체)

-스프링 컨테이너는 싱글톤 컨테이너임(싱글톤 레지스트리: 싱글톤 생성 및 관리)

-스프링 컨테이너 덕분에 이미 만들어진 객체를 공유해서 효율적으로 재사용 가능

 

싱글톤 방식의 주의점(실무에서 매우 중요)

-하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게(stateful) 설계하면 안됨

-무상태하게 설계(stateless)

    -가급적 Read만 가능

    -특정 클라이언트 의존 X

    -특정 클라이언트가 값을 변경 할수 X

    -지역변수, 파라미터, ThreadLocal등을 사용

    -공유값 설정 X