[inflearn] 스프링 핵심 원리 - 기본편

개발자·2022년 1월 10일

객체지향

다형성

자동차, 운전자가 있을 때
자동차 종류가 바뀌어도 운전자는 운전 가능
운전자는 자동차 내부 구조를 몰라도 됨.

역할과 구현으로 구분하면 단순, 유연, 변경이 편리해짐.
클라이언트는 구현 대상의 내부를 알 필요 없고 내부 구조가 변경되어도 영향받지 않는다.
대상의 역할만 알면 된다.
클라이언트는 구현 대상 자체를 변경해도 영향 받지 않는다.

역할 : 인터페이스
구현 : 인터페이스를 구현한 클래스

다형성의 본질

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야한다.
클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있어야 한다.

** 중요
유연, 변경 용이
확장 가능한 설계
클라이언트에 영향을 주지 않는 설계
인터페이스를 안정적으로 설계하는 것이 중요

SRP

책임의 기준은 변경이다.
변경이 있을 때 파급 효과가 적으면 잘 따른 것

OCP

확장에는 열려있으나 변경에는 닫혀있어야함.
다형성을 활용하면 됨!
인터페이스를 구현한 새로운 클래스를 만들어 새로운 기능 구현

LSP

다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 함.
인터페이스를 구현한 구현체를 믿고 사용하려면 필요한 원칙.
기능이 제대로 동작하는 것을 보장하는 느낌

ISP

클라이언트 별로 인터페이스 분리
자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
인터페이스가 명확해지고 대체 가능성이 높아진다.

DIP

추상화에 의존해야지, 구체화에 의존하면 안된다
즉 구현 클래스가 아닌 인터페이스에 의존해야 함.

MemberRepository m = new MemoryMemberRepository();
-> OCP, DIP 위반

다형성 만으로는 OCP, DIP를 지킬 수 없다!

스프링은 DI(의존관계 주입), DI 컨테이너 두 기능으로 다형성+OCP,DIP를 가능하게 함.
But, 인터페이스를 도입하면 추상화라는 비용이 발생한다. 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 추후에 리팩토링으로 인터페이스를 도입해도 된다.

MemberServiceImpl/OrderServiceImpl은 MemoryMemberRepository를 의존 X. 아예 소스코드에 MemoryMemberRepository가 없음
Appcongfig에서 지정해주면 MemberServiceImpl의 생성자를 통해 주입됨.
의존관계를 외부에서 주입해주는 것 처럼 보이므로 DI, 의존성 주입이라고 함.

제어의 역전 IoC

기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.
반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램 제어 흐름은 AppConfig가가 가져간다. OrderServiceImpl은 필요한 인터페이스를 호출하지만 어떤 구현 객체들이 실행될지 모른다.
이렇게 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (나는 필요한 부분만 개발하면 프레임워크가 제어)
반면 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리이다.

의존관계 주입 DI

OrderServiceImpl은 DiscountPolicy 인터페이스에 의존한다. 실제 어떤 구현 객체가 사용될지는 모른다(Fix/Rate)
의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 한다.

정적인 클래스 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 애플리케이션을 실행하지 않고도 분석할 수 있다.
OrderServiceImpl은 MemberReposioty, DiscountPolicy에 의존한다는 것을 알 수 있다.
근데 이러한 클래스 의존관계만으로는 실제 어떤 객체가 OrderServiceImpl에 주입될 지 알 수 없다.

동적인 객체 의존관계

애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.
MemberRepository -> MemoryMemberRepository
DiscountPolish -> RateDiscountPolicy
애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다. -> MemberRepository, DiscountPolicy 건드리지 않고 Memory/DB, Fix/Rate 변경 가능

IoC 컨테이너, DI 컨테이너

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.
의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.
또는 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.

스프링 컨테이너 생성

스프링 컨테이너는 XML기반/애노테이션 기반의 자바 설정 클래스(AppConfig)로 만들 수 있다.
빈 이름은 항상 다르게 부여해야한다. 중복 X
스프링 컨테이너 => 설정 정보(AppConfig 참조해서 의존관계를 주입함)

BeanFactory

스프링 컨테이너의 최상위 인터페이스.
스프링 빈을 관리하고 조회하는 역할.
getBean() 제공

ApplicationContext

BeanFactory 기능을 모두 상속받아 제공
그 외에 추가로 메세지 소스, 환경변수(로컬/개발/운영 구분 처리), 어플리케이션 이벤트, 편리한 리소스 조회 기능 제공

BeanDefinition

빈 설정 메타 정보 -> @Bean, <bean>당 메타 정보가 하나씩 생성된다.
스프링 컨테이너는 이 메타 정보를 기반으로 스프링 빈을 생성한다.
즉, 역할과 구현을 개념적으로 나눈 것

XML을 읽어 BeanDefinition을 만든다.
자바 코드를 읽어 BeanDefinition를 만든다.
스프링 컨테이너는 XML인지 자바 코드인지 몰라도 된다. BeanDefinition만 알면 된다.

=> 스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것

싱글톤

스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청할 때 마다 객체를 새로 생성함. 즉 MemberService를 호출할 때 마다 새 객체를 만드는 것. -> 메모리 낭비가 심함
객체를 하나만 생성하고 공유하는 싱글톤 패턴을 사용하는 것이 좋음
객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 함.

소스 코드

private static final SingletonService instance = new SingletonService();

public static SingletonService getInstance() {
	return instance;
}

private SingletonService() {
}

static 영역에 객체 instance를 미리 생성해 올려둔다.
getInstance를 메서드를 통해서만 인스턴스를 조회할 수 있다.
인스턴스가 1개만 존재해야하므로 Singleton 생성자를 private으로 만들어 외부에서 new로 생성되는 것을 막는다.

문제점

구현 코드 자체가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존한다. -> DIP 위반 & OCP도 위반할 가능성이 높아진다.
테스트가 어렵다.(이미 처음에 설정이 다 되어버려서)
내부 속성을 변경하거나 초기화 하기 어렵다.
private 생성자로 자식 클래스 만들기가 어렵다.
유연성이 떨어진다.

But!!!!!!!! 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하며, 객체 인스턴스를 싱글톤으로 관리한다.

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하며, 객체 인스턴스를 싱글톤으로 관리한다. (빈 객체를 생성하고 등록해 관리함.)
지금까지 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.

스프링 컨테이너는 싱글톤 패턴을 등록하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 단점을 해결하며 객체를 싱글톤으로 유지할 수 있다.(지저분한 코드, DIP/OCP/테스트/private 생성자로부터 자유롭게 사용 가능)

-> 고객 요청이 올 때 마다 객체를 생성하는 것이 아니라 이미 만들어진 객체를 공유해 효율적으로 재사용할 수 있다.
(참고 : 스프링 컨테이너의 기본 빈 등록 방식은 싱글톤이지만, 요청할 때 마다 새로운 객체를 생성해 반환하는 기능도 제공한다)

주의점

여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다. stateless로 설계해야 한다.

특정 클라이언트에 의존적인 필드가 있으면 안된다.
특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
가급적 읽기만 가능해야 한다.
필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

오류 예제

public class StatefulService {
    private int price;
    
    public void order(String name, int price) {
    	this.price = price; // 여기가 문제!!
    }
    
    public int getPrice() {
    	return price;
    }
}

void main() {
    StatefulService statefulService1 = ac.getBean(StatefulService.class);
    StatefulService statefulService2 = ac.getBean(StatefulService.class);

    statefulService1.order("userA", 10000);
    statefulService2.order("userB", 20000);

    int price = statefulService1.getPrice(); // A는 10000을 주문했지만 20000이 되어있음
}

!! 공유 필드를 조심하자! 스프링 빈은 항상 Stateless(무상태)로 설계해야 한다 !!

수정 예제

public class StatefulService {
    private int price;
    
    public int order(String name, int price) {
    	return price; // 이렇게 수정해서 쓰는게 좋음
    }
}

@Configuration

하단 소스코드의 상황에서 new MemoryMemberRepository();가 memberService, orderService에 의해 두 번 호출 된다.
결과적으로 각각 다른 두 개의 MemoryMemberRepository가 생성되며 싱글톤이 깨지는 것 처럼 보이지만 @Configuration이 해결해준다.
(@Configuration은 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다. 클래스명에 지정해주며 @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());
}

직접 검증해보면 memberRepository1와 memberRepository2가 동일한 것을 확인할 수 있다.

MemberRepository memberRepository1 = memberService.getMemberRepository();
MemberRepository memberRepository2 = orderService.getMemberRepository();

참고

AppConfig 스프링 빈을 조회해 클래스 정보를 확인해보면 AppConfig 뒤에 낯선 이름이 붙어있는 것을 확인할 수 있다.(ex. AppConfig$$EnhancerBySpringCHLIB##bd479....)
이것은 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다.
그 임의의 다른 클래스가 싱글톤이 보장되도록 해준다!

즉, MemberRepository가 이미 스프링 컨테이너에 등록되어 있으면 스프링 컨테이너에서 찾아서 반환하고, 없으면 기존 로직을 호출해 MemoryMemberRepository를 생성해 스프링 컨테이너에 등록한다. 덕분에 싱글톤이 보장되는 것이다.

@Configuration을 빼면?

싱글톤이 보장되지 않고 memberRepository 메소드를 통해 MemoryMemberRepository가 new로 여러번 생성된다.

정리

@Bean만 사용해도 스프링 빈으로 등록되지만, @Configuration이 없으면 싱글톤을 보장하지는 않는다.
그러므로 스프링 설정정보에는 @Configuration를 사용하자!

컴포넌트 스캔

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.
이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.

생성자에 @Autowired를 지정하면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.

탐색 위치

꼭 필요한 위치부터 탐색하도록 basePackages를 사용해 시작 위치를 지정할 수 있다.
But, 권장하는 방법은 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다.
이렇게 하면 프로젝트 최상단을 포함한 하위는 모두 자동으로 컴포넌트 스캔의 대상이 된다.
ex) com.hello에 설정 정보를 두고 @ComponentScan 애노테이션을 붙이면 com.hello를 포함한 하위는 모두 컴포넌트 스캔 대상이 된다.

스프링 부트를 사용하면 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 이 프로젝트 시작 루트 위치에 두는 것이 관례이다. (그리고 이 설정안에 @ComponentScan 이 들어있다.)

컴포넌트 스캔 기본 대상

@Component : 컴포넌트 스캔에서 사용
@Controller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용
@Configuration : 스프링 설정 정보에서 사용

컴포넌트 스캔의 용도 뿐만 아니라 다음 애노테이션이 있으면 스프링은 부가 기능을 수행한다.

@Controller : 스프링 MVC 컨트롤러로 인식
@Service : 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 계층을 인식하는데 도움이 된다.
@Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
@Configuration : 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.

중복 등록과 충돌

자동 빈 등록 vs 자동 빈 등록
컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다
수동 빈 등록 vs 자동 빈 등록
이 경우 수동 빈 등록이 우선권을 가진다(수동 빈이 자동 빈을 오버라이딩 해버린다).
But!! 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다.

의존관계 자동 주입

의존관계 주입 방법 => 여기

롬복과 최신 트렌드

롬복 라이브러리 적용 방법

dependency 추가
Preferences(윈도우 File -> Settings) -> Plugins -> lombok 검색 설치 실행 (재시작)
Preferences -> Annotation Processors 검색 -> Enable annotation processing 체크 (재시작)

Annotation

@Getter
@Setter
@ToString
@RequiredArgsConstructor : final이 붙은 필드를 모아 생성자 만들어줌.

조회 대상 빈이 2개 이상일 때

ex) DiscountPolicy -> RateDiscountPolicy, FixDiscountPolicy 2개이므로 오류

@Autowired
private DiscountPolicy discountPolicy

해결 방법

@Autowired 필드명 매칭

@Autowired 는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

@Autowired
private DiscountPolicy rateDiscountPolicy

1) 타입 매칭
2) 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

@Qualifier 사용

빈 등록시 @Qualifier를 붙여 준다. 사용할 때도 @Qualifier로 찾는다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

-> @Qualifier("mainDiscountPolicy") 를 못찾으면 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다.
But, @Qualifier는 @Qualifier를 찾는 용도로만 사용하는게 명확하다.

@Qualifier 찾을 때
1) @Qualifier끼리 매칭
2) 빈 이름 매칭
3) NoSuchBeanDefinitionException 예외 발생

@Primary 사용

@Primary 는 우선순위를 정하는 방법이다.
@Autowired 시에 여러 빈이 매칭되면 @Primary 가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Qualifier의 단점은 주입 받을 때 다음과 같이 모든 코드에 @Qualifier를 붙여주어야 한다는 점이다. 반면 @Primary를 사용하면 @Qualifier를 붙일 필요가 없다.

@Primary, @Qualifier 활용

코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고, 코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 생각해보자. 메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary를 적용해서 조회하는 곳에서 @Qualifier 지정 없이 편리하게 조회하고, 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier를 지정해서 명시적으로 획득 하는 방식으로 사용하면 코드를 깔끔하게 유지할 수 있다. 물론 이때 메인 데이터베이스의 스프링 빈을 등록할 때 @Qualifier를 지정해주는 것은 상관없다.
우선순위 : @Qualifier > @Primary

애노테이션 직접 만들기

@Qualifier("mainDiscountPolicy") 처럼 직접 문자를 적으면 컴파일시 타입 체크가 안되므로 직접 만들어서 해결할 수 있다.

여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다. @Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다. 단적으로 @Autowired도 재정의 할 수 있다. 물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있다.

조회한 빈이 모두 필요할 때

ex) DiscountPolicy -> RateDiscountPolicy, FixDiscountPolicy 둘 다 필요한 경우
=> Map, List로 해결 가능

예제 )

static class DiscountService {
	// 의존성 주입
    private final Map<String, DiscountPolicy> policyMap;
    private final List<DiscountPolicy> policies;

	// 생성자 1개 이므로 autowired 생략 가능
    public DiscountService(
        Map<String, DiscountPolicy> policyMap, 
        List<DiscountPolicy> policies) 
    {
        this.policyMap = policyMap;
        this.policies = policies;
    }
    
    // discount(member, 10000, "fixDiscountPolicy"); 
    // 이런 방식으로 호출해서 사용
	public int discount(Member member, int price, String discountCode) {
		DiscountPolicy discountPolicy = policyMap.get(discountCode);
		return discountPolicy.discount(member, price);
	}
}

로직 분석

DiscountService는 Map으로 모든 DiscountPolicy 를 주입받는다. 이때 fixDiscountPolicy , rateDiscountPolicy 가 주입된다.
discount() 메서드는 discountCode로 "fixDiscountPolicy"가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아서 실행한다.

주입 분석

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다. 만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다.

의존관계 주입 자동 VS 수동

업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 딱! 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋다.

비즈니스 로직 중에서 다형성을 적극 활용할 때
조회한 빈이 모두 필요할 때의 상황에서는 어떤 빈이 주입될지 한눈에 파악하기 힘드므로 수동 빈으로 등록하거나 자동으로 특정 패키지에 같이 묶어두는게 좋다. -> 한눈에 이해하기 편하게 하기 위해서

정리

편리한 자동 기능을 기본으로 사용하자
직접 등록하는 기술 지원 객체는 수동 등록
다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

빈 생명주기 콜백

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

스프링은 객체 생성 -> 의존관계 주입의 라이프사이클을 가진다.
스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까?

스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다.

스프링 빈의 이벤트 라이프사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
소멸전 콜백: 빈이 소멸되기 직전에 호출

참고: 객체의 생성과 초기화를 분리하자.
생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행한다. 따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다는 객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다. 물론 초기화 작업이 내부 값들만 약간 변경하는
정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다.

참고: 싱글톤 빈들은 스프링 컨테이너가 종료될 때 싱글톤 빈들도 함께 종료되기 때문에 스프링 컨테이너가 종료되기 직전에 소멸전 콜백이 일어난다. 뒤에서 설명하겠지만 싱글톤 처럼 컨테이너의 시작과 종료까지 생존하는 빈도 있지만, 생명주기가 짧은 빈들도 있는데 이 빈들은 컨테이너와 무관하게 해당 빈이 종료되기 직전에 소멸전 콜백이 일어난다. 자세한 내용은 스코프에서 알아보겠다

스프링의 빈 생명주기 콜백 지원 방법

1. 인터페이스(InitializingBean, DisposableBean)

InitializingBean 은 afterPropertiesSet() 메서드로 초기화를 지원한다.
DisposableBean 은 destroy() 메서드로 소멸을 지원한다.

public class NetworkClient implements InitializingBean, DisposableBean {

	...
    
    @Override
    public void afterPropertiesSet() throws Exception {
		connect();
        call("초기화 연결 메시지");
    }
    
    @Override
    public void destroy() throws Exception {
		disConnect();
	}
 
}

초기화, 소멸 인터페이스 단점

이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
초기화, 소멸 메서드의 이름을 변경할 수 없다.
내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

=> 참고: 인터페이스를 사용하는 초기화, 종료 방법은 스프링 초창기에 나온 방법들이고, 지금은 다음의 더 나은 방법들이 있어서 거의 사용하지 않는다.

2. 빈 등록 초기화, 소멸 메서드 지정

public class NetworkClient {

	...
    
    public void init() { 		
    	System.out.println("NetworkClient.init"); 	
        connect();
		call("초기화 연결 메시지");
	}
    
	public void close() {
    	System.out.println("NetworkClient.close");
		disConnect();
	}
 
}

@Configuration
static class LifeCycleConfig {

	@Bean(initMethod = "init", destroyMethod = "close")
	public NetworkClient networkClient() {
		NetworkClient networkClient = new NetworkClient();
		networkClient.setUrl("http://hello-spring.dev");
		return networkClient;
	}
}

설정 정보 사용 특징

메서드 이름을 자유롭게 줄 수 있다.
스프링 빈이 스프링 코드에 의존하지 않는다.
코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다.

종료 메서드 추론

@Bean의 destroyMethod 속성에는 아주 특별한 기능이 있다.
라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
@Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.
이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다.
따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다.
추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정하면 된다. -> 굳이?..

3. @PostConstruct, @PreDestroy 애노테이션

이 방법 추천!!

public class NetworkClient {

	...
    
    @PostConstruct
    public void init() { 		
    	System.out.println("NetworkClient.init"); 	
        connect();
		call("초기화 연결 메시지");
	}
    
    @PreDestroy
	public void close() {
    	System.out.println("NetworkClient.close");
		disConnect();
	}
 
}

@Configuration
static class LifeCycleConfig {

	@Bean
	public NetworkClient networkClient() {
		NetworkClient networkClient = new NetworkClient();
		networkClient.setUrl("http://hello-spring.dev");
		return networkClient;
	}
}

@PostConstruct, @PreDestroy 애노테이션 특징

최신 스프링에서 가장 권장하는 방법이다.
애노테이션 하나만 붙이면 되므로 매우 편리하다.
패키지를 잘 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.
컴포넌트 스캔과 잘 어울린다.
유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자.

결론

@PostConstruct, @PreDestroy 애노테이션을 사용하자

코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean 의 initMethod , destroyMethod 를 사용하자.

빈 스코프

스프링이 지원하는 스코프

싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.
프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.
웹 관련 스코프
- request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
- session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.
- application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

빈 스코프 지정

컴포넌트 스캔 자동 등록

@Scope("prototype")
@Component
public class HelloBean {}

수동 등록

@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
	return new HelloBean();
}

프로토타입 스코프

프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

과정

프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.
스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

프로토타입 빈의 특징

스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다. 클라이언트에 빈을 반환하고, 이후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않는다. 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있다. 그래서 @PreDestroy 같은 종료 메서드가 호출되지 않는다.

빈 조회 시 싱글톤 vs 프로토타입 차이점

싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행 되지만, 프로토타입 스코프의 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고 초기화 메서드도 실행된다.
싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료 메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화 까지만 관여하고, 더는 관리하지 않는다. 따라서 프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestroy 같은 종료 메서드가 전혀 실행되지 않는다.

프로토타입 빈 정리

스프링 컨테이너에 요청할 때 마다 새로 생성된다.
스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
종료 메서드가 호출되지 않는다.
그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.

프로토타입 스코프와 싱글톤 빈을 함께 사용한다면?

문제점

스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다. 그런데 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 생성 시점에 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되므로 사용할 때마다 새로 생성되지 않는다.

해결 방법

가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때 마다 스프링 컨테이너에 새로 요청하는 것이다.

@Autowired
private ApplicationContext ac;

public int logic() {
	PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
	prototypeBean.addCount();
	int count = prototypeBean.getCount();
	return count;
}

실행해보면 ac.getBean() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL) 의존관계 조회(탐색)이라한다.
그런데 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워진다.

ObjectFactory, ObjectProvider

ObjectProvider : 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것. ObjectFactory에 편의 기능을 추가해서 ObjectProvider 가 만들어졌다.

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
	PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
	prototypeBean.addCount();
	int count = prototypeBean.getCount();
	return count;
}

실행해보면 prototypeBeanProvider.getObject() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.(DL)
스프링이 제공하는 기능을 사용하지만, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

ObjectFactory: 기능이 단순, 별도의 라이브러리 필요 없음, 스프링에 의존
ObjectProvider: ObjectFactory 상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요 없음, 스프링에 의존

JSR-330 Provider

마지막 방법은 javax.inject.Provider 라는 JSR-330 자바 표준을 사용하는 방법이다.
이 방법을 사용하려면 javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야 한다.

@Autowired
private Provider<PrototypeBean> provider;

public int logic() {
	PrototypeBean prototypeBean = provider.get();
	prototypeBean.addCount();
	int count = prototypeBean.getCount();
	return count;
}

실행해보면 provider.get() 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다. provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

특징

get() 메서드 하나로 기능이 매우 단순하다.
별도의 라이브러리가 필요하다.
자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.

그러면 프로토타입 빈을 언제 사용할까? 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 그런데 실무에서 웹 애플리케이션을 개발해보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.

ObjectProvider , JSR330 Provider 등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용할 수 있다.

ObjectProvider를 사용하고 스프링이 아닌 다른 컨테이너에서 사용해야한다면 JSR-330 Provider를 사용하자.

웹 스코프

특징

웹 스코프는 웹 환경에서만 동작한다.
웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다.

종류

request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.
session: HTTP Session과 동일한 생명주기를 가지는 스코프
application: 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

예제

@Controller
@RequiredArgsConstructor
public class LogDemoController {
	private final LogDemoService logDemoService;
	private final MyLogger myLogger;
    
	@RequestMapping("log-demo")
	@ResponseBody
	public String logDemo(HttpServletRequest request) {
		String requestURL = request.getRequestURL().toString();
		myLogger.setRequestURL(requestURL);
		myLogger.log("controller test");
		logDemoService.logic("testId");
		return "OK";
	} 
}

스프링 애플리케이션은 실행 시점에 싱글톤 빈을 생성해서 주입하지만 requset 스코프 빈은 실제 요청이 와야 생성되므로 해당 코드는 오류가 발생한다.

해결 방법

Provider를 사용한다.

ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다.
ObjectProvider.getObject()를 호출하는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리된다.
ObjectProvider.getObject()를 LogDemoController, LogDemoService 에서 각각 한번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환된다!

@Controller
@RequiredArgsConstructor
public class LogDemoController {
	private final LogDemoService logDemoService;
	private final ObjectProvider<MyLogger> myLoggerProvider;
    
	@RequestMapping("log-demo")
	@ResponseBody
	public String logDemo(HttpServletRequest request) {
		String requestURL = request.getRequestURL().toString();
		MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);
		myLogger.log("controller test");
		logDemoService.logic("testId");
		return "OK";
	} 
}

프록시 방식을 사용한다.

MyLogger 클래스를 수정하고 logDemo 클래스는 원래대로 되돌린다.
CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS) 를 설정하면 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성한다.
결과를 확인해보면 우리가 등록한 순수한 MyLogger 클래스가 아니라 MyLogger$ $EnhancerBySpringCGLIB이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있다.
그리고 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다.
ac.getBean("myLogger", MyLogger.class)로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있다.
그래서 의존관계 주입도 이 가짜 프록시 객체가 주입된다.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
	...
}

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

클라이언트가 myLogger.logic() 을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
가짜 프록시 객체는 request 스코프의 진짜 myLogger.logic() 를 호출한다.
가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다(다형성)

정리

동작 정리

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다.

특징 정리

프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

주의점

마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에(요청마다 생성됨) 결국 주의해서 사용해야 한다.
이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.

개발자

log.info("공부 기록 블로9")

이전 포스트

[Programmers] 괄호 회전하기

다음 포스트

[inflearn] 스프링 핵심 원리 - 기본편

객체지향

다형성

다형성의 본질

SRP

OCP

LSP

ISP

DIP

제어의 역전 IoC

의존관계 주입 DI

정적인 클래스 의존관계

동적인 객체 의존관계

IoC 컨테이너, DI 컨테이너

스프링 컨테이너 생성

BeanFactory

ApplicationContext

BeanDefinition

싱글톤

문제점

싱글톤 컨테이너

주의점

@Configuration

참고

@Configuration을 빼면?

정리

컴포넌트 스캔

탐색 위치

컴포넌트 스캔 기본 대상

중복 등록과 충돌

의존관계 자동 주입

롬복과 최신 트렌드

롬복 라이브러리 적용 방법

Annotation

조회 대상 빈이 2개 이상일 때

해결 방법

@Primary, @Qualifier 활용

애노테이션 직접 만들기

조회한 빈이 모두 필요할 때

로직 분석

주입 분석

의존관계 주입 자동 VS 수동

정리

빈 생명주기 콜백

스프링 빈의 이벤트 라이프사이클

스프링의 빈 생명주기 콜백 지원 방법

1. 인터페이스(InitializingBean, DisposableBean)

2. 빈 등록 초기화, 소멸 메서드 지정

3. @PostConstruct, @PreDestroy 애노테이션

빈 스코프

스프링이 지원하는 스코프

빈 스코프 지정

프로토타입 스코프

과정

프로토타입 빈의 특징

빈 조회 시 싱글톤 vs 프로토타입 차이점

프로토타입 빈 정리

프로토타입 스코프와 싱글톤 빈을 함께 사용한다면?

문제점

해결 방법

ObjectFactory, ObjectProvider

JSR-330 Provider

웹 스코프

특징

종류

예제

해결 방법

정리

동작 정리

특징 정리

주의점

[Programmers] 괄호 회전하기

[inflearn] 스프링 핵심 원리 - 기본편

0개의 댓글