@Configuration은 사실 싱글톤을 위해 존재하는 것이다. 그런데 이상한 점이 있다. 이전에 작성했던 AppConfig 코드를 다시 확인해보자. @Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } @Bean public OrderService orderService(){ return new OrderServiceImpl(memberRepository(..
싱글톤 패턴이던 스프링 같은 싱글톤 컨테이너를 사용하던, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다. 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal...등을 사용해야 한다. 스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 발생할 수 있다.
싱글톤 컨테이너에 대해 알아보자. 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 싱글톤으로 관리되는 빈이다. 싱글톤 컨테이너 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 이전에 설명한 컨테이너 생성 과정을 보면 컨테이너 객체를 하나만 생성해서 관리한다. 즉, 스프링 컨테이너는 싱글톤 컨테이너 역할을 하는 것이다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다. 스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다. 다음과 같은 테스트코드를 작성해 직접 확인해보자. @Test @Display..
싱글톤 패턴은, 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 한 JVM 안에서는 객체 인스턴스가 딱 하나만 생성되도록 만드는 것이다. 결론은, 똑같은 타입의 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 하는 것이다. 코드로 살펴보자. package hello.core.singleton; public class SingletonService { //1. static 영역에 객체를 딱 1개만 생성해둔다. private static final SingletonService instance = new SingletonService(); //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다. public static Sin..
이번 포스팅부터는 싱글톤 컨테이너에 대해 알아보자. 싱글톤 패턴은 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴하는 것을 말한다. 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 그래서 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 할 수 있다. 웹 애플리케이션은 보통 여러 클라이언트가 동시에 요청을 한다. 위 상황에서 클라이언트가 3번의 요청을 하면 3개의 객체가 생성된다. 이렇게 되면 요청이 올 때마다 계속 객체를 생성해야 하는 문제가 발생한다. 이를 코드를 이용해 테스트를 해보자. 다음은 스프링을 사용하지 않은 DI 컨테이너이다. ..
이번 포스팅에서는 BeanFactory와 ApplicationContext에 대하여 알아보자. 최상위에 BeanFactory 인터페이스가 있고, 이를 상속받은 ApplicationContext 인터페이스가 있다. 이를 통해 BeanFactory에 부가기능을 더한 것이라고 이해할 수 있다. 이 밑에 우리가 사용했던 ApplicationConfig와 같은 구현 객체가 있다. 하나씩 살펴보자. BeanFactory 스프링 컨테이너의 최상위 인터페이스이다. 이 BeanFactory에 .getBean()... 과 같이 스프링 빈을 관리하고 조회하는 기능이 모두 들어있다. 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다. ApplicationContext BeanFactory 기능..
내 블로그 - 관리자 홈 전환 |
Q
Q
|
---|---|
새 글 쓰기 |
W
W
|
글 수정 (권한 있는 경우) |
E
E
|
---|---|
댓글 영역으로 이동 |
C
C
|
이 페이지의 URL 복사 |
S
S
|
---|---|
맨 위로 이동 |
T
T
|
티스토리 홈 이동 |
H
H
|
단축키 안내 |
Shift + /
⇧ + /
|
* 단축키는 한글/영문 대소문자로 이용 가능하며, 티스토리 기본 도메인에서만 동작합니다.