728x90
- 발생 원인
- 순수 자바 컨테이너로 만들었던 AppConfig를 웹 애플리케이션으로 직접 사용하면 요청할 때마다 설정파일 내의 객체를 새로 생성하고 삭제하는 과정을 거친다.
- 메모리 낭비가 심하다.
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer(){
AppConfig appConfig = new AppConfig();
MemberService memberService1 = appconfig.memberService();
MemberService memberService2 = appconfig.memberService();
assertThat(memberService1).isNotSameAs(memberService2);
}
- 해결방안
- 해당 객체를 1개만 생성하고 공유하도록 설계 한다. == 싱글톤 패턴
- 싱글톤
- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
- private constructor를 사용해서 외부에서 new keyword를 사용하지 못하도록 한다.
1. 싱글톤 패턴
- 싱글톤 패턴 적용시, 요청 때 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용한다.
- 싱글톤 패턴 작성
- 싱글톤을 적용할 class의 instance를 해당 class 내부에 작성
private static final ClassType instance = new ClassType(){}; - 해당 객체 사용하려면 getter를 통해서만 사용하도록 한다.
public static ReturnType getter() {}; - 생성자를 private으로 선언해서 해당 class instance 생성을 막는다.
private ClassName () {}
- 싱글톤을 적용할 class의 instance를 해당 class 내부에 작성
- JUnit5
- isSameAs() : java의 == 과 동일, 객체 주소까지 비교 의미
- equeals() : java의 equals와 동일, 주소가 아닌 값 비교 의미
@Test
@DisplayName("싱글톤 패턴 적용한 객체 시용")
public void singletonServiceTest(){
SingletonService singletonService1 = SingletonService.getInstance();
SingletonSErvice singletonService2 = SingletonService.getInstance();
// new SingletonService(); // error
asserThat(singletonService1).isSameAs(singletonService2);
}
// [다른 class]
// 싱글톤 패턴을 적용한 class
public class SingletonService{
// static 영역에 객체를 딱 1개만 생성한다.
private static final SingletonService instance = new SingletonService();
// public으로 열어서 객체 인스턴스가 필요시, 이 static 메서드를 통해서만 조회
public static SingletonService getInstance(){
return instance;
}
// 생성자를 private으로 선언, 외부에서 new keyword 사용한 객체 생성 막음
private SingletonService(){};
}- singleton 패턴 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다. ex) getInstance()로 직접 구현체 가져옴
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 테스트하기 어렵다.
- 내부 속성을 변경하거나 초기화 하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어렵다.
- 결론적으로 유연성이 떨어진다.
- Spring Container
- 싱글톤 컨테이너라고 한다.
- 빈을 저장할 때 싱글톤 방식으로 저장한다.
- 해당 패턴의 문제점을 전부 보완했다.
2. 싱글톤 컨테이너
- 스프링 컨테이너 : 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
- 스프링 컨테이너의 Spring Bean은 싱글톤으로 관리되는 Bean
@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void SpringContainer(){
// AppConfig appConfig = new AppConfig();
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
Assertions.assertThat(memberService1).isSameAs(memberService2);
}
- 정리
- 스프링 컨테이너: 싱글톤 컨테이너 역할 수행
- 싱글톤 레지스트리: 싱글톤 객체를 생성하고 관리하는 기능
- 스프링 컨테이너 싱글톤의 장점
- 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
- DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.
- 스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
- 참고
- 스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아니다.
- 빈스코프 기능 제공 : 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능 제공
⭐️ 3. 싱글톤 방식의 주의점
- 하나의 객체를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안 된다.
- 싱글톤뿐만이 아니라 하나의 객체를 공유하는 부분은 아주아주 주의 필요
다른 client로 인해서 현 client data가 변경되기 때문
- 싱글톤뿐만이 아니라 하나의 객체를 공유하는 부분은 아주아주 주의 필요
- 무상태(stateless) 설계
- 특정 client에 의존적인 필드가 있으면 안 된다. = only read
- 특정 client가 값을 변경할 수 있는 필드가 있으면 안된다.
- 필드 대신에 java에서 공유되지 않는 lv, params, ThreadLocal 등을 사용
- stateful 문제점 코드
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;
};
}package hello.core.singleton;
class StatefulServiceTest {
@Test
void statefulServiceSingleton() {
ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
// @Configuration 없이 해당 class를 통채로 스프링컨테이너에 등록. 내부에는 @Bean이 있긴 해야함
StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService statefulService2 = ac.getBean("statefulService",StatefulService.class);
statefulService1.order("a", 10000);
statefulService1.order("b", 20000);
int price = statefulService1.getPrice();
assertThat(price).isEqualTo(20000);
}
static class TestConfig {
@Bean
public StatefulService statefulService(){
return new StatefulService();
}
}
}- 싱글톤 주의 사항 위배
- StatefulService의 price 필드는 공유필드인데, 특정 클라이언트가 값을 변경
- 진짜 공유필드는 조심해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계
- 지역변수를 통해서 price를 출력하도록 한다.
- stateful 문제점 해결
// 변경 전
public class StatefulService{
private int price; // 값 공유 하는 이 부분이 문제 = stateful 하다
public void order(String name, int price){ this.price = price; }
public int getPrice(){ return price; };
}
// 변경 후
public class StatelessService{
public int order(String name, int price){
return price; // 지역변수로 값을 넘겨준다 = stateless 하다
}
}
// TEST 변경 전
@Test
void statfulServiceSingleton(){
'''생략'''
statefulService1.order("userA", 10000);
statefulService1.order("userB", 20000);
int price = statefulService1.getPrice();
Assertions.asserThat(price).isEqualTp(20000); // userA는 10000원인데 20000원이 나옴
}
//// TEST 변경 후
@Test
void statfulServiceSingleton(){
'''생략'''
// 지역변수 price 값을 담는 int 변수 생성
int userAPrice = statefulService1.order("userA", 10000);
int userBPrice = statefulService1.order("userB", 20000);
Assertions.asserThat(price).isEqualTp(10000); // userA는 10000원 나옴
}
4. @Configuration, 싱글톤
- @Configuration 은 싱글톤을 위해서 존재한다.
- AppConfig (@Configuration 존재)
- memberReopsitory()를 2번 호출 -> 생성자를 이용한 객체 생성이므로 싱글톤을 위배한 것이 정상적인 java 동작 방식
- 하지만 test를 수행하면 싱글톤이 깨지지 않는다. ->모두 동일한 인스턴수가 공유
@Configuration
public class AppConfig {
@Bean // spring container 에 넣기
public MemberRepository memberRepository() { return new MemoryMemberRepository(); }
@Bean
public DiscountPolicy discountPolicy() { return new RateDiscountPolicy(); }
@Bean
public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } // 1번
@Bean
public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } // 2번
}- test1
public class SingleTonTest {
@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();
System.out.println("singletonService2 = " + singletonService2);
System.out.println("singletonService1 = " + singletonService1);
Assertions.assertThat(singletonService1).isSameAs(singletonService2);
}
@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void SpringContainer(){
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
Assertions.assertThat(memberService1).isSameAs(memberService2);
}
}- test
package hello.core.singleton;
public class ConfigurationSingletonTest {
@Test
void configurationTest() {
ApplicationContext 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);
MemberRepository memberRepository1 = memberService.getMemberRepository();
MemberRepository memberRepository2 = orderService.getMemberRepository();
System.out.println(memberRepository1);
System.out.println(memberRepository2);
System.out.println(memberRepository);
Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
}
@Test
void configurationDeep(){
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean);
System.out.println("bean.getClass = " + bean.getClass());
}
}
5. @Configuration과 바이트코드 조작의 마법
@Test
void configurationDeep(){
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
// CGLIB
System.out.println("bean = " + bean); // hello.core.AppConfig$$SpringCGLIB$$0@37e4d7bb
System.out.println("bean.getClass = " + bean.getClass()); // hello.core.AppConfig$$SpringCGLIB$$0
}5.1. 싱글톤이 유지되는 이유
- spring은 클래스의 바이트코드를 조작하는 라이브러리를 사용 ( 라이브러리 = CGLIB )
- @Configuration이 포함된 AppConfig: CGLIB를 이용해서 조작된 AppConfig$$SpringCGLIB$$0@74a6f9c1 로 springContainer에 등록
- @Bean 객체 : 해당 조작AppConfig를 통해 싱글톤이 적용되도록 springContainer에 등록
5.2. @Configuration
- @Configuration은 사실 singleton을 위해 존재
- @Configuration을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장
- @Configuration 없이 @Bean만 존재해도 springContainer에 등록이 가능: 하지만 싱글톤이 유지가 안된다.
- 작동방식
- spring은 @Configuration 존재 설정파일을 찾는다.
- 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 AppConfig@CGLIB를 만든다.
- 새로 만들어진 AppConfig@CGLIB로 @Bean을 등록한다.
- 등록 시 동일 인스턴스를 사용하면 springContainer에 미리 생성된 객체를 사용
- 해당 인스턴스가 없으면 생성한다.
- 결론: 싱글톤이 보장되도록 해준다
- 그림
- CGLIB 예상 로직
// AppConfig@CGLIB 예상 로직
@Bean public MemberRepository memberRepository() {
if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
return 스프링 컨테이너에서 찾아서 반환;
} else { //스프링 컨테이너에 없으면
기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
return 반환
}
}
6. BeanDefinition 과 CGLIB
- BeanDefinition과 @Configuration의 CGLIB 작동 순서
- @Configuration이 붙은 클래스는 CGLIB를 사용하여 자바 프록시 객체를 생성
- @Bean이 붙은 메서드는 해당 클래스의 프록시 객체 내부에서 호출
- @Bean 메서드에서 생성된 객체는 해당 클래스의 프록시 객체 내부에 등록
- @Bean 메서드에서 생성된 객체는 BeanDefinition이라는 객체로 변환되어 스프링 컨테이너에 등록
- 정리
- @Configuration이 붙은 클래스는 CGLIB를 사용하여 프록시 객체를 생성하고, 해당 클래스 내부의 @Bean 메서드에서 생성된 객체들은 BeanDefinition 객체로 변환되어 스프링 컨테이너에 등록
- 이렇게 생성된 BeanDefinition 객체들은 스프링 컨테이너가 시작될 때 미리 생성되어 관리
이전 발행글: 스프링 핵심 원리 이해 3 - 스프링 컨테이너와 스프링 빈
다음 발행글: 스프링 핵심 원리 이해 5 - 컴포넌트 스캔