이번에 섹션에서는 싱글톤 컨테이너에 대해 알아보자.
목차는 다음과 같다.
1) 웹 애플리케이션과 싱글톤
2) 싱글톤 패턴
3) 싱글톤 컨테이너
4) 싱글톤 방식의 주의점
5) @Configuration과 싱글톤
6) @Configuration과 바이트코드 조작의 마법
먼저 웹 어플리케이션에서 왜 싱글톤이 많이 사용되는지와 그 이유에 대해 알아보고, 싱글톤 패턴에 대해 알아보자. 그리고 싱글톤 컨테이너, 싱글톤 방식의 주의점에 대해 알아보고, 스프링이 제공하는 @Configuration의 비밀에 대해서도 파헤쳐보자.
먼저, 웹 애플리케이션과 싱글톤에 대해 알아보자.
- 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.
- 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있다. (ex. 배치 애플리케이션, 데몬 애플리케이션 등)
- 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
아래 그림을 보자.
코드로 확인해보자.
✔️ 정리
👉 코드로 적용해보자.
getInstance()
메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.👉 테스트를 진행해보자.
✔️ 참고
⚠️ 싱글톤 패턴 문제점
: 싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 다음과 같은 수 많은 문제점들을 가지고 있다.
스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.
✔️ 싱글톤 컨테이너
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
- 이전에 설명한 컨테이너 생성 과정을 자세히 보자. 컨테이너는 객체를 하나만 생성해서 관리한다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
- 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
- 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
- DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.
👉 테스트를 통해 확인해보자.
👉 싱글톤 컨테이너 적용 후
스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
(참고) 스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아니다. 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다. 자세한 내용은 뒤에 빈 스코프에서 설명하겠다.
이번 강의에서는 싱글톤 방식의 주의점에 대해 알아보자.
✔️ 싱글톤 방식의 주의점
- 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
- 무상태(stateless)로 설계해야 한다.
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
- 가급적 읽기만 가능해야 한다. (가급적 값을 수정하면 안된다.)
- 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
- 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다.
👉 상태를 유지할 경우 발생하는 문제점을 예시를 통해 알아보자.
StatefulService
의 price
필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.이번에는 @Configuration의 비밀에 대해 파헤쳐보자.
❓ 이전에 만들었던 AppConfig를 보면, 의문점이 한가지 있다.
memberRepository()
를 호출한다.new MemoryMemberRepository()
를 호출한다.memberRepository()
를 호출한다.new MemoryMemberRepository()
를 호출한다.🤔 결과적으로 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것 처럼 보인다. (분명 스프링 컨테이너는 싱글톤을 보장해준다고 했는데..) 스프링 컨테이너는 이 문제를 어떻게 해결할까?
👉 직접 확인해보자.
new MemoryMemberRepository
호출해서 다른 인스턴스가 생성되어야 하는데?❓어떻게 위와 같은 결과가 나온것일까 🤔
스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 위 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다.
그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
모든 비밀은 @Configuration을 적용한 AppConfig에 있다.
👉 다음 코드를 보자.
AppConfig
스프링 빈을 조회해서 클래스 정보를 출력해보자.)AnnotationConfigApplicationContext
에 파라미터로 넘긴 구성 정보도 스프링 빈으로 등록된다. 그래서 AppConfig
도 스프링 빈이 된다.class hello.core.AppConfig
와 같이 출력되어야 하지만, 뒤에 뭔가 붙어있다. ($$EnhancerBySpringCGLIB$$68989ba6
)
👉 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다! (그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다.)
🤔 만약 @Configuration
을 적용하지 않고, @Bean
만 적용하면 어떻게 될까?
: @Configuration
을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean만 적용하면 어떻게 될까?
확인해보자.
bean = class hello.core.AppConfig
call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository
memberRepository()
를 호출하면서 발생한 코드다.
✔️ 정리
@Configuration
없이 @Bean만 사용해서 스프링 빈을 등록해도 싱글톤으로 등록된다. 싱글톤이 안되고, 문제가 되는 부분은 @Bean으로 수동 등록할 때, 내부의 의존관계를 직접 메서드 호출로 주입할 때만 발생한다. 이때 문제를 해결해주는 것이 @Configuration
애노테이션이다. (memberRepository()
처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.)@Configuration
을 사용하자.강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 김영한 강사님께 있습니다.