📖 1. 웹 어플리케이션과 싱글톤
이전까지 JAVA 기반 설정파일과 XML 기반 설정파일을 읽어 BeanDefinition을 만들어 스프링 컨테이너를 생성하며 학습을 하였다.
그럼으로써 OCP. DIP 원칙을 지키며 객체지향 프로그래밍 원칙인 SOLID도 지킬 수 있었다.
하지만, 아직 고려해야할 부분이 많이 남아있다.
그 중 하나가 구성영역의 appConfig.class 코드쪽이다.
스프링 애플리케이션을 동시에 실행할 때마다 스프링 컨테이너에서 서비스 계층으로 주입되어야 할 수많은 객체들이 생성된다.
이는 몹시 비효율적이고 메모리낭비이다.
문제점 : 요청이 올때마다 계속 객체를 만들어야 한다.
- 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인
AppConfig는 요청을 할 때마다 객체를 새로 생성한다.
➡️ 메모리 낭비가 심하다.
test/../hello.core/singleton/SingletonTest
package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
public class SingletonTest {
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContatiner(){
AppConfig appConfig = new AppConfig();
// 1. 조회 : 호출할 때마다 객체 생성
MemberService memberService1 = appConfig.memberService();
// 2. 조회 : 호출할 때마다 객체 생성
MemberService memberService2 = appConfig.memberService();
// 3. 참조값 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// memberService != memberService2
Assertions.assertThat(memberService1).isNotSameAs(memberService2);
}
}
실행 결과
문제점 해결방안
- 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다.
- 이를 싱글톤 패턴이라고 한다.
📖 2. 싱글톤 패턴
클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
- private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.
test/../singleton/SingletonService.java
package hello.core.singleton;
public class SingletonService {
// 1. static 영역에 객체를 딱 1개만 생성해둔다.
// 자기 자신을 내부에 private로 가지는데, static으로 가짐
private static final SingletonService instance = new SingletonService();
// public으로 열어서 객체 인스턴스가 필요하면 이 static 메소드를 통해 조회하도록 허용
public static SingletonService getInstance() {
return instance;
}
// 생성자를 private으로 선언해 외부에서 new 키워드를 사용한 객체 생성을 못하도록 막음
private SingletonService() {
}
public void logic() {
System.out.println("싱글톤 객체 로직 호출");
}
}
(1) static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
(2) 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
(3) 딱 1개의 객체 인스턴스만 존재해야하므로, 생성자 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.
싱글톤 패턴을 구현하는 방법은 여러 가지가 있다. 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했다.
싱글톤 패턴을 사용하는 테스트 코드
test/../singleton/SingletonTest.java
package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
public class SingletonTest {
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContatiner(){
AppConfig appConfig = new AppConfig();
// 1. 조회 : 호출할 때마다 객체 생성
MemberService memberService1 = appConfig.memberService();
// 2. 조회 : 호출할 때마다 객체 생성
MemberService memberService2 = appConfig.memberService();
// 3. 참조값 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// memberService != memberService2
Assertions.assertThat(memberService1).isNotSameAs(memberService2);
// isSameAs는 동일성비교로 연산자 == 와 동일하며 isEqualTo가 동등비교로 equals연산자와 동일하다.
// 간단히 말해 동일비교는 참조값 비교, 동등비교는 내용물(값) 비교
}
}
private으로new키워드를 막아 두었기 때문에 생성자를 만들려고 하면 컴파일 오류가 발생한다.- 호출할 때마다 같은 객체 인스턴스를 반환하는 것을 알 수 있다.
이렇듯 싱글톤 패턴을 적용하면 고객의 요청이 올때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 다음과 같은 수많은 문제점들을 가지고 있다.
싱글톤 패턴의 문제점
- 싱글톤 패턴을 적용하기 위해 구현할 코드의 양이 많아지면서 비용이 늘어난다.
- 의존관계상 클라이언트가 구체 클래스에 의존하게 되면서,
DIP,OCP원칙을 위반하게 된다. - 테스트하기 어렵다. (인스턴스를 미리 다 받아서 설정이 끝난 상태이기 때문에 유연한 테스트를 하기 힘들다.)
- 내부 속성을 변경하거나 초기화하기 어렵다.
private생성자로 자식 클래스를 만들기 어렵다.- 결론적으로 유연성이 떨어진다.
- 안티패턴(
anti-pattern)으로 불리기도 한다.
(안티 패턴 : 실제 많이 사용되는 패턴이지만 비효율적이거나 비생산적인 패턴)
📖 3. 싱글톤 컨테이너
스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 싱글톤으로 객체들을 관리한다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이처럼 싱글톤 객체를 생성 및 관리하는 기능을 싱글톤 레지스트리라고 한다.
- 이렇게 스프링 컨테이너에서 싱글톤 컨테이너 역할을 해줌으로써 싱글톤 패턴의 단점을 없애고 객체의 단일성을 유지할 수 있다.
→ 그렇기에 각각의 빈들은 싱글톤 패턴 적용을 위한 코드를 작성할 필요가 없다.
→ DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.
싱글톤 컨테이너 적용
test/../hello.core/singleton/SingletonTest
package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import static org.assertj.core.api.Assertions.*;
public class SingletonTest {
~
@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContatiner(){
//AppConfig appConfig = new AppConfig();
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
// 1. 조회 : 호출할 때마다 객체 생성
MemberService memberService1 = ac.getBean("memberService",MemberService.class);
MemberService memberService2 = ac.getBean("memberService",MemberService.class);
// 3. 참조값 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// memberService != memberService2
assertThat(memberService1).isSameAs(memberService2);
// isSameAs는 동일성비교로 연산자 == 와 동일하며 isEqualTo가 동등비교로 equals연산자와 동일하다.
// 간단히 말해 동일비교는 참조값 비교, 동등비교는 내용물(값) 비교
}
}
실행 결과
스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
참고 : 스프링의 기본 빈 등록 방식은 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다. 자세한 내용은 뒤에 빈 스코프에서 알 수 있다.
📖 4. 싱글톤 방식의 주의점
싱글톤 컨테이너든, 싱글톤 패턴이든 싱글톤을 사용한다면 주의해야하는 부분이 있다.
싱글톤 패턴에서는 객체 인스턴스를 하나만 생성해서 공유하는 방식이기 때문에 여러 클라이언트에서 해당 인스턴스를 공유하게된다.
그렇기 때문에 해당 객체가 상태를 유지하는 stateful방식의(유지) 객체이면 문제가 발생한다.
그러므로, 상태를 유지하지 않는 stateless 상태로(무상태, 유지하지 않게) 객체를 설계해야 한다.
❗️상태를 유지하지 않는 객체를 설계하기 위해서는❗️
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신 JAVA에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal등을 사용해야 한다.
싱글톤 객체가 상태를 유지할 경우 문제가 발생한다.
test/../hello.core/singleton/StatefulService
package hello.core.singleton;
public class StatefulService {
private int price; // 상태를 유지하는 필드
public void order(String name, int price){
System.out.println("name = " + name + "price = " + price);
this.price = price;
}
public int getPrice(){
return price;
}
}
test/../hello.core/singleton/StatefulServiceTest
package hello.core.singleton;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import static org.junit.jupiter.api.Assertions.*;
class StatefulServiceTest {
@Test
void statefulServiceSingleton(){
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean(StatefulService.class);
StatefulService statefulService2 = ac.getBean(StatefulService.class);
// ThreadA : A사용자 10000원 주문
statefulService1.order("userA",10000);
// ThreadA : A사용자 20000원 주문
statefulService1.order("userB",20000);
// ThreadA : 사용자A 주문 금액 조회
int price = statefulService1.getPrice();
System.out.println("price = "+price);
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
static class TestConfig{
@Bean
public StatefulService statefulService(){
return new StatefulService();
}
}
}
실행 결과
(catsbi블로그 참고한 내용입니다!)
🔔 테스트 코드를 보면서 드는 의문점
분명 10000원을 주문한userA의 price를 조회하는데 어째서 결과 값이 20000원이 나왔을까?답안 : 두 개의 객체 인스턴스인
statefulService1와statefulService2가 같은 객체 인스턴스StatefulService객체를 바라보기 때문이다.
statefulService1에서userA가 10000원을 주문하면서 price에 10000원이 대입되었지만, 그 뒤statefulService2에서userB가 20000원을 주문했다. 그래서 price에는 20000원이 대입되는데 여기서 price 필드는 싱글톤으로 하나의 객체 인스턴스를 통해 공유되기 때문에userA는 자신이 주문한 뒤 주문한userB의 금액이 입력되는 것이다.
그렇기에, 싱글톤을 사용할 때는 해당 객체 인스턴스에 공유필드가 있어서는 안된다.
즉, 싱글톤을 사용하려면 상태가 없어야(stateless)한다.
📖 5. @Configuration과 싱글톤
스프링 컨테이너는, 싱글톤 컨에티너 역할을 해서 빈들을 하나만 생성해 관리한다.
이를 위해 구성영역 AppConfig소스를 다시 한 번 확인하자!
java/hello.core/AppConfig.java
package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
// @Configuration : 설정, 구성정보를 나타낸다.
@Configuration
public class AppConfig {
// @Bean memberService -> new MemoryMemberRepository()
// @Bean orderService -> new MemoryMemberRepository();
// 깨질지 안깨질지 고민하지말고, TestCase로 검사한다.
// 어디서든 Appconfig를 통해 멤버 서비스를 불러다 쓸 수 있다.
// 생성자 주입
// @Bean : 스프링 컨테이너에 등록하겠다.
@Bean
public MemberService memberService(){
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService(){
// 구체적인 것을 여기서 선택하도록 한다.
// 생성자 주입
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
@Bean
public DiscountPolicy discountPolicy(){
// return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}
여기서 memberService와 orderService를 확인하면, 각각 자신의 구현체를 생성해서 반환하는데, 그 내부 파라미터를 보면 둘 다 memberRepository를 호출하고 있다.
그런데, memberRepository 내부 코드는 MemoryMemberRepository 인스턴스를 생성해 반환하는 것이다.
memberService, orderService, memberRepository에서 총 세 번 내부 코드가 실행되는데, 싱글톤이 어떻게 유지되는지 궁금할 것이다.
우리의 생각한대로라면 해당 구성정보의 빈들이 등록되면 memberService, orderService, memberRepository에서 꺼낸 각각의 memberRepository의 객체 참조주소가 달라야한다.
이를 코드를 통해 실행해보자!
java/hello.core/member/MemberServiceImpl.java
package hello.core.member;
public class MemberServiceImpl implements MemberService{
// 가입을 하고 회원을 찾으려면 앞서 만든 MemberRepository 인터페이스가 필요하다.
// private final MemberRepository memberRepository = new MemoryMemberRepository();
private final MemberRepository memberRepository;
~
// 테스트 용도
public MemberRepository getMemberRepository(){
return memberRepository;
}
}
java/hello.core/order/OrderServiceImpl.java
package hello.core.order;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
public class OrderServiceImpl implements OrderService{
// 멤버 레포지토에서 회원을 찾기 위함
private final MemberRepository memberRepository;
~
// 테스트 용도
public MemberRepository getMemberRepository(){
return memberRepository;
}
}
test/../hello.core/singleton/ConfigurationSingletonTest.java
package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberRepository;
import hello.core.member.MemberServiceImpl;
import hello.core.order.OrderServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import static org.assertj.core.api.Assertions.*;
public class ConfigurationSingletonTest {
@Test
void configurationTest(){
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
OrderServiceImpl orderService = ac.getBean("orderService",OrderServiceImpl.class);
MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);
// 모두 같은 인스턴스를 참고하고 있다.
System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
System.out.println("orderService -> memberRepository = " + orderService.getMemberRepository());
System.out.println("memberRepository = " + memberRepository);
assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
}
}
실행 결과
실행결과를 보면 세 가지 빈의 memberRepository의 참조값이 모두 같은 것을 알 수 있다.
코드상으로 memberRepository가 3번 호출되면 MemoryMemberRepository객체 인스턴스는 세 개가 생겨야 하는데 왜 모두가 동일한 걸까?
이를 확인하기 위해 AppConfig에 로깅 코드를 넣어서 확인하자!
java/hello.core/AppConfig.java
package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
// @Configuration : 설정, 구성정보를 나타낸다.
@Configuration
public class AppConfig {
// @Bean memberService -> new MemoryMemberRepository()
// @Bean orderService -> new MemoryMemberRepository();
// 깨질지 안깨질지 고민하지말고, TestCase로 검사한다.
// 예상되는 출력 순서
// call AppConfig.memberService
// call AppConfig.memberRepository
// call AppConfig.memberRepository
// call AppConfig.orderService
// call AppConfig.memberRepository
// 결과 (singleton은 어떻게든 single을 보장)
// call AppConfig.memberService
// call AppConfig.memberRepository
// call AppConfig.orderService
// 어디서든 Appconfig를 통해 멤버 서비스를 불러다 쓸 수 있다.
// 생성자 주입
// @Bean : 스프링 컨테이너에 등록하겠다.
@Bean
public MemberService memberService(){
System.out.println("call AppConfig.memberService");
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemberRepository memberRepository() {
System.out.println("call AppConfig.memberRepository");
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService(){
// 구체적인 것을 여기서 선택하도록 한다.
// 생성자 주입
System.out.println("call AppConfig.orderService");
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
@Bean
public DiscountPolicy discountPolicy(){
// return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}
실행 결과
우리의 예상과는 다르게 memberRepository 메서드는 단 한 번만 호출되었다.
이유는 다음 강의에서 알 수 있다!
📖 6. @Configuration과 바이트코드 조작의 마법
스프링 컨테이너는 싱글톤 레지스트리이기 때문에 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.
그런데 스프링이 자바 코드끼리 조작하기는 어렵기 때문에, 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
모든 비밀은 @Configuration을 적용한 AppConfig에 있었다.
다음 테스트를 실행해보면서 @Configuration 어노테이션을 적용한 AppConfig.class의 클래스타입을 확인해보자❗️
test/../hello.core/singleton/ConfigurationSingletonTest.java
package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberRepository;
import hello.core.member.MemberServiceImpl;
import hello.core.order.OrderServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import static org.assertj.core.api.Assertions.*;
public class ConfigurationSingletonTest {
~
@Test
void configurationDepp(){
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean.getClass());
}
}
실행 결과
우리가 만든 AppConfig.class 라면 hello.core.AppConfig가 출력되야 정상이다.
하지만, 실행 결과에서는 AppConfig 뒤에 예상치 못한 글자가 길게 붙어 있다.
💡이유는?
내가 만든 클래스가 아니라, 스프링에서CGLIB라는 바이트코드 조작 라이브러리를 사용해서AppConfig클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록했기 때문이다.
다음과 같은 바이트 코드를 조작해서 작성되어 있을 것이다.이렇게 바이트코드 조작을 통해 만들어진 `AppConfig@CGLIB` 에서 싱글톤이 보장되도록 해준다. 그러면서도 해당 객체는 `AppConfig` 의 자식 타입으로 만들어져 `AppConfig` 타입으로 조회가 가능하다.
@Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다. (덕분에 싱글톤이 보장된다.)- 즉, 내부 로직은 스프링 빈이 없으면 기존 클래스의 생성로직을 수행하고, 스프링 빈이 있으면 존재하는 스프링 빈을 반환하도록 로직이 되어있을 것이다.
덕분에 싱글톤이 보장되는 것이다.
참고 :
AppConfig@CGLIB는AppConfig의 자식 타입이므로,AppConfig타입으로 조회할 수 있다.
그렇다면 @Configuration을 적용하지 않고 @Bean만 적용한다면?
AppConfig에서 @Configuration 어노테이션을 지우고 실행 해보자❗️
java/hello.core/AppConfig
실행 결과
AppConfig가 CGLIB 기술 없이 순수한 AppConfig 로 스프링 빈에 등록된 것을 확인할 수 있다.
이제 memberRepository의 참조주소 값이 어떻게 바뀌는지 확인해보자❗️
test/../hello.core/singleton/ConfigurationSingletonTest.java
실행 결과
memberRepository는 3번 호출되었고 각각의 서비스에 등록된 memberRepository의 참조주소 값이 모두 다르다.
그렇기에, 테스트는 실패하고 각각 모두 다른 MemoryMemberRepository 인스턴스를 갖게된다.
🔔 정리
@Bean으로만 등록해도 스프링 빈으로 등록은 되지만, 싱글톤을 보장하지 않는다.memberRepository()와 같이 의존관계 주입이 필요한 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.- 스프링은 보장되지 않기에, 스프링 설정 정보는 항상
@Configuration을 사용하도록 하자❗️
참고
