본 게시글은 인프런 김영한 선생님 강의 스프링 핵심 원리를 완강하고 배운 것을 남기고자 적은 포스팅입니다.
강의 링크는 아래와 같습니다.
(강의 예제 코드는 웬만하면 적지 말라고 강의 공지사항에 적혀 있어서 이해 가능하게 코드를 짧게 남기겠습니다)
스프링 핵심 원리 - 기본편 - 인프런 | 강의
스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., 스프링 핵심 원리를 이해하고, 성장하는 개발자가 되어보세요! 📢 수강 전
www.inflearn.com
시작하겠습니다.
스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.
대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 웹 애플리케이션은 보통 여러 클라이언트가 동시에 요청을 한다.
우리의 AppConfig 즉 스프링 @Configuration을 붙이지 않은 순수 자바 DI 컨테이너는 new 연산자를 이용해 매번 새로운 객체를 클라이언트에게 제공한다. 엄청나게 많은 고객이 동시에 요청하면 객체가 생성되고 소멸된다. 이는 극심한 메모리의 낭비로 이어진다. 이런 메모리 낭비를 위한 해결방안으로는 객체가 딱 1개 생성되고, 공유하도록 설계하면 된다. 이를 싱글톤 패턴이라고 한다.
싱글톤 패턴이란 무엇인가?
- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
- 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
- private 생성자를 사용해서 외부에서 new 키워드를 사용하지 못하도록 막아야 한다.
간단한 싱글톤 패턴 예제 코드를 살펴보겠다.
public class SingletonService{
// 1. static 영역에 객체를 딱 1개만 생성한다.
private static final SingletonService singletonService = new SingletonService();
// 2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
public static SingletonService.getInstance(){
return instance;
}
// 3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
private SingletonService(){
}
public void logic(){
System.out.println("싱글톤 객체 로직 호출");
}
}
statuc 영역에 객체 인스턴스를 미리 하나 생성해서 올려둔다.
이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.
이렇게 우리는 싱글톤 패턴을 사용했다. 이제 같은 객체만 반환되면서 우리 메모리의 낭비를 지킬 수 있다.
그러나 이 싱글톤 패턴에는 단점이 존재한다.
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. 즉 DIP 위반.
- 클라이언트가 구체 클래스에 의존해서 OCP를 위반할 가능성이 높다.
- 테스트가 어렵고, 내부 속성을 변경하거나 초기화하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어려우며 결론적으로 유연성이 떨어진다.
우리 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(오직 1개)으로 관리한다.
지금까지 필자가 포스팅한 스프링 빈은 모두 싱글톤으로 관리되는 빈이다.
싱글톤 컨테이너
- 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 컨테이너는 객체를 하나만 생성해서 관리한다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
- 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
- 즉 싱글톤 패턴을 위한 더러운 코드가 안들어가며, DIP, OCP, TEST, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.
스프링의 싱글톤 컨테이너를 적용한 후 클라이언트에게 제공되는 빈은 다음 그림과 같다.
이제 중요한 싱글톤 방식의 주의점을 살펴보자.
싱글톤은 즉 여러 클라이언트가 하나의 객체 인스턴스를 공유한다.
그러므로 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안 된다.
무상태로 설계해야 한다!!!!
- 특정 클라이언트에 의존적인 필드가 있으면 안 된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!!!
항상 스프링 빈은 무상태(stateless)로 설계하자.
이제 AppConfig에서 찜찜한 코드를 봐보자.
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public OrderService orderService() {
return new OrderServiceImpl(
memberRepository(),
discountPolicy());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
...
}
위 코드에서 new 연산자를 통해 MemoryMemberRepository()의 호출을 2번 한다. 바로 orderService 빈을 만드는 코드와 memberService를 만드는 코드에서 호출한다. 이러면 new 연산자를 통해 2번 호출되면서 객체가 2개 생성되며 싱글톤이 깨지는 것으로 보인다. 스프링 컨테이너는 어떻게 이를 해결할까?
바로 답하자면 orderService 객체를 만들고 memberService 객체를 만들어서 이 객체가 의존하는 MemoryMemberRepository를 조회해보면 같은 인스턴스다. 즉 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용되는 것이다. 신기하게도 new 연산자를 호출하면 다른 인스턴스가 생성되어야 하는데 그렇지 않았다.
생성자에서 호출해보면 놀랍게도 new 연산자는 1번만 호출되었다.
이것이 가능한 이유는 @Configuration과 바이트코드 조작의 마법 때문이다.
스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해야 한다. 그런데 스프링이 자바 코드까지 어떻게 조작하기는 어렵다. 분명히 new 생성자를 이용해서 인스턴스가 여러 번 호출되어야 한다.
그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
AppConfig도 스프링 빈으로 등록된다. 그래서 AppConfig 스프링 빈을 조회해서 클래스 정보를 출력하면,
bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479 d70
이런 이상한 클래스가 나온다. 우리가 예상한 순수 클래스는 class hello.core.AppConfig 이런 형식일 텐데..
이를 통해 알 수 있는 것은 이 클래스는 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다.
아래 그림과 같다.
즉 AppConfig@CGLIM는 @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다. 덕분에 싱글톤이 보장되는 것이다.
만약 @Configuration을 적용하지 않고, @Bean만 적용하면 어떻게 될까?
@Configuration을 붙이면 바이트 코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean만 적용하면 어떻게 될까? 결과를 말하자면 싱글톤이 깨진다. 즉 위에 코드에서 살펴본 MemberRepository 생성자가 여러 번 호출되면서 새로운 객체를 반환한다.
즉 @Bean 만 사용하면 스프링 빈으로는 등록되지만, 싱글톤은 보장하지 않는다. @Configuration을 붙이면 싱글톤을 보장한다.
이상으로 마치겠습니다
댓글