티스토리 뷰
웹 애플리케이션과 싱글톤
웹 애플리케이션은 보통 여러 고객이 동시 요청을 요구함 -> 요청마다 객체를 생성해야 함 -> 좋지 않은 방법..
해결 방안? - 해당 객체를 1개만 생성하고, 생성된 객체를 공유하도록 설계한다. ==> 싱글톤 패턴
싱글톤 패턴( Singleton Pattern )
클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴
어떻게 보장? - private 생성자를 사용해 외부에서 임의로 new 키워드 사용하지 못하게 하여 보장
위의 코드는 객체를 미리 생성해두는 단순하고 안전한 방법, 다른 여러 싱글톤 패턴도 존재한다.
장점만 존재하는가? 문제점은?
싱글톤 패턴을 구현하기 위한 코드가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존한다. - DIP위반
클라이언트가 구체 클래스에 의존하여 OCP를 위반할 수 있다.
내부 속성을 변경하기, private 생성자로 자식 클래스 생성이 어렵다 - 유연하지 못한다.
싱글톤 컨테이너
스프링 컨테이너는 위 문제점을 해결하며, 객체 인스턴스를 싱글톤으로 관리해준다.
스프링 빈이 싱글톤으로 관리되는 빈이다. ( 이전 스프링 빈 포스팅 )
즉 스프링 컨테이너는 스프링 빈을 등록하고, 요청이 올때마다 미리 만들어진 객체를 반환하는 것이다.
싱글톤 방식의 주의점
객체 인스턴스를 하나만 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 객체 인스턴스를 공유한다.
싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됨, 인스턴스의 값이 변경되버려..
그러므로 항상 무상태(stateless, 상태정보를 저장하지 않는 상태)로 설계
@Configuration과 싱글톤
우리는 싱글톤 방식을 사용하기로 했는데 위 코드는 그런 부분에서 옳지 않다.
memberService() -> memberReposiory() -> MemoryMemberRepository()
orderService() -> memberRepository() -> MemoryMemberRepository()
2개의 MemoryMemberRepository가 생성된다. (코드로만 보면)
하지만 그렇지 않다. 같은 인스턴스를 공유하여 사용한다. 어떻게..?
@Configuration과 바이트코드 조작의 마법
스프링이 내가 만든 클래스명에 CGLIB라는 바이트코드 조작 라이브러리를 사용하여
클래스를 상속받은 임의의 다른 클래스를 만들고, 이를 스프링 빈에 등록하는 과정으로 싱글톤을 보장해준다.
AppConfig@CGLIB의 코드는 아마 @Bean 붙은 메서드가 스프링 빈에 존재하면 반환하고
없다면 생성해서 스프링 빈으로 등록하여 반환하는 과정이 있지 않을까..
..
@Bean만 사용해도 스프리빈으로 등록되지만, 싱글톤을 보장하지 않는다. -> 매번 객체 생성
설정 정보를 @Configuration을 사용하자
..
본 포스팅은 인프런 강의 김영한님의
[ 스프링 핵심 원리 - 기본편 ] 을 수강하며 작성한 내용입니다.