[Spring] 빈 생명주기 콜백, 빈 스코프

- 김영한 님의 '스프링 핵심원리 - 기본편'을 보고 정리한 글입니다 😊

스프링 핵심 원리 - 기본편 - 인프런 | 강의

---

- 지난 포스팅과 이어집니다 :D

[Spring] 컴포넌트 스캔과 의존관계 자동 주입

- 스프링 핵심원리 강의의 마지막 정리가 될 것 같습니다 🤭

 

 

| 빈 생명주기 콜백

- DB 커넥션 풀 같은 작업은 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 종료 시점에 한 번에 종료하는 게 낫다.

   - 스프링에서는 이런 초기화 및 종료 작업을 어떻게 할까?

- 간단한 예제 코드를 통해서 알아보자.

 

[NetworkClient.java]

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메시지");
    }

    public void setUrl(String url) {
        this.url = url;
    }

    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message: " + message);
    }

    public void disconnect() {
        System.out.println("close: " + url);
    }
}

 

✔ Test

[BeanLifeCycleTest.java]

public class BeanLifeCycleTest {
    @Test
    public void lifeCycleTest() throws Exception {
        ConfigurableApplicationContext ac
                = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        NetworkClient networkClient = ac.getBean(NetworkClient.class);
        ac.close(); // 스프링 컨테이너 종료
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean
        public NetworkClient networkClient() {
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hi.dev");
            return networkClient;
        }
    }
}

✔ 실행 결과

생성자 호출, url = null
connect: null
call: null message: 초기화 연결 메시지

 

- 분명 기대한 건 setUrl을 통해 넣어진 url 값이 나와야 하는데, null이 찍힌 것을 확인할 수 있다.

- 이는 당연하다. 객체를 생성하는 단계에서는 url이 초기화되지 않은 상태이기 때문이다. 우리는 생성된 이후 수정자로 url을 주입하였다.

url을 담은 결과를 받고 싶다면 외부에서 networkClient.connect() 혹은 .call()을 호출해야 찍히게 된다.

 

🚩 사실, 예제에서 setUrl()을 하는 게 과연 '의존관계 주입'의 관점에서 볼 수 있을까... 라는 의문이 들 수 있다.

기본적으로 '의존관계를 주입한다' 라는 관점에서 보면, url을 외부로부터 주입받기 때문에 의존관계 주입이라고 볼 수 있다.

그러나, DI를 수행하는 궁극적인 이유는 '추상화된 것에 의존'하여 '결합도'를 낮추기 위함이다.

위 예제에서 setUrl()을 진행할 때 url의 타입은 String이어서 별도의 인터페이스 타입이 아니기 때문에 결합도를 낮춘다는 관점에서 보면 의존관계 주입이라고 보기는 어렵다. (이 부분 찾아보면서 개인적으로 DI에 대해 다시 생각해볼 수 있었다.)

 

 

⭐ 스프링 빈은 객체 생성 -> 의존관계 주입 순으로 일어난다.

- 즉, 객체가 생성되고 의존관계 주입이 끝나야만 데이터를 사용할 수 있기 때문에 초기화도 그 이후에 진행되어야 한다.

- 스프링은 의존관계 주입 완료 시, 스프링 빈에게 콜백 메서드를 통해 초기화 시점을 알려주며, 소멸 전에도 소멸 콜백을 날린다.   

- InitializingBean, DisposableBean Interface 

- 설정 정보에 초기화 메서드, 종료 메서드 지정   

- @PostConstruct, @PreDestroy

 

즉, 다음과 같은 라이프 사이클을 가진다고 볼 수 있다.

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

 

- ⭐ 단,  생성자 주입에서는 객체를 생성할 때 스프링 빈이 함께 들어와야 하기 때문에 객체 생성 및 의존관계 주입이 동시에 일어난다.

    - 객체 생성 시 생성자에 파라미터가 존재한다면, 해당 파라미터에는 이미 만들어진 스프링 빈이 들어와야 주입할 수 있으니까. 

 

- 참고로, 유지보수 관점에서도 생성자 내부에서 초기화를 진행하는 건 별로 좋지 않다.

생성자는 객체를 생성하고, 초기화하는 부분은 따로 나누어야 유지보수 시 더 낫다. (간단한 작업이라면 생성자 내에서 해도 되겠지만)

---

| 빈 생명주기 콜백 - InitializingBean, DisposableBean

- 위에서 사용하였던 NetworkClient 예제를 수정해보자.

[NetworkClient.java]

public class NetworkClient implements InitializingBean, DisposableBean {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message: " + message);
    }

    public void disconnect() {
        System.out.println("close: " + url);
    }

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

    @Override
    public void destroy() throws Exception {
        disconnect();
    }
}

- InitializingBean, DisposableBean 인터페이스를 구현하여 afterPropertiesSet(), destroy() 함수를 오버라이딩 하였다.

- 기존에 생성자에서 진행하였던 connect, call 작업을 afterPropertiesSet()에서 진행하도록 변경하였다.

- 각각은 초기화, 소멸을 지원하는 메서드라고 생각하면 된다!

 

✔ 실행 결과

생성자 호출, url = null
connect: http://hi.dev
call: http://hi.dev message: 초기화 연결 메시지
17:31:45.756 [Test worker] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@1cdc4c27, started on Sun Aug 07 17:31:45 KST 2022
close: http://hi.dev

- 테스트를 실행해보면 성공적으로 url이 잘 들어간 걸 볼 수 있다.

- 이는 값 주입 이후(setUrl) 각 함수가 호출되고 소멸되었기 때문이다.

- 단, 위 방법은 인터페이스를 구현해야 하기 때문에 스프링 인터페이스에 의존하며, 초기화/소멸 메서드 이름의 변경이 불가능하다.

    - 사실상, 위 방법은 거의 사용하지 않는다고 봐도 무방하다.

 

🚩 외부 라이브러리에 종속적이면 무엇이 안 좋을까?

- 코드를 작성하게 되면 JVM에 의해서 .class -> .java로 변경이 되는데, .class의 경우 컴파일이 되어버린 상태이기 때문에 수정이 어렵다.

개발자의 입장에서는 작성한 소스코드를 수정하지만, 실제로 프로그램이 동작할 때는 소스코드뿐만 아니라 여러 외부 라이브러리도 함께 사용하는데,

외부 라이브러리는 이미 .class로 컴파일이 되어 있는 상태이기 때문에 개발자가 직접 수정할 수 없다.

 

---

| 빈 생명주기 콜백 - 초기화, 소멸 메서드 지정

- 빈 등록 시 설정 정보에 initMethod, destroyMethod를 지정할 수 있다. 다시 예제를 수정해보자.

[NetworkClient.java]

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message: " + message);
    }

    public void disconnect() {
        System.out.println("close: " + url);
    }

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

    public void close() {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

[BeanLifeCycleTest.java]

public class BeanLifeCycleTest {
    @Test
    public void lifeCycleTest() throws Exception {
        ConfigurableApplicationContext ac
                = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        NetworkClient networkClient = ac.getBean(NetworkClient.class);
        ac.close(); // 스프링 컨테이너 종료
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean(initMethod = "init", destroyMethod = "close")
        public NetworkClient networkClient() {
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hi.dev");
            return networkClient;
        }
    }
}

- @Bean에 initMethod와 destroyMethod를 추가해주었다. 참고로, 이름을 잘못 입력하면 컴파일 시점에 에러난다. (신기...!)

 

✔ 실행 결과

생성자 호출, url = null
NetworkClient.init
connect: http://hi.dev
call: http://hi.dev message: 초기화 연결 메시지
17:53:36.244 [Test worker] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@1cdc4c27, started on Sun Aug 07 17:53:35 KST 2022
NetworkClient.close
close: http://hi.dev

- 결과가 잘 나오는 걸 볼 수 있다. 인터페이스를 구현하지 않아도 되며, 메서드 이름을 변경할 수 있다는 장점이 있다!

- 특히, destroyMethod의 경우, default 값이 (inferred)이기 때문에 close(), shutdown()이라는 이름의 메서드를 자동 호출한다.

    - 그래서 위 예제에서는 따로 destroyMethod를 지정하지 않아도 잘 동작한다 :D

 

🚩 추가적으로, 위 방법은 @Bean에서만 적용을 할 수 있다. 자동 등록하는 @Component에서는 사용이 불가능하다.

그래서 보통 세 번째로 나오는 방법을 가장 많이 사용한다 :)

 

---

| 빈 생명주기 콜백 - @PostConstruct, @PreDestroy

- 개인적으로 가장 선호하는 방법이다. 아마 가장 많이 사용하지 않을까...

[NetworkClient.java]

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message: " + message);
    }

    public void disconnect() {
        System.out.println("close: " + url);
    }

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

    @PreDestroy
    public void close() {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

- 다음과 같이 @PostConstruct, @PreDestroy를 붙여주면 된다.

- 테스트 코드의 @Bean도 원래대로 돌려놓자. 잘 돌아간다.

 

- 위 방법의 경우 해당 어노테이션은 자바 표준이기 때문에 스프링에 종속적이지 않다는 특징이 있다.

- 그러나, 외부 라이브러리에는 적용할 수 없기 때문에 (개발자가 직접 외부 라이브러리의 코드를 수정할 수 없으니까)

그때는 @Bean의 initMethod를 사용해주는 것이 좋다.

 

---

| 빈 스코프

- 스프링 빈은 기본적으로 스프링 컨테이너의 시작과 종료까지 유지된다. 이는 싱글톤 스코프이기 때문이다.

🚩 싱글톤이기 때문에 컨테이너에서 항상 같은 인스턴스의 스프링 빈을 반환하는 것이다.

 

- 싱글톤 외에도 다양한 스코프가 존재한다.

- 싱글톤: 기본, 스프링 컨테이너의 시작과 종료까지 유지

- 프로토타입: 프로토타입 빈의 생성 및 의존관계까지만 관여하고 관리 X, 매우 짧다

- 웹 (request) : 웹 요청이 들어오고 나갈 때까지

- 웹 (session) : 웹 세션이 생성되고 종료될 때까지

- 웹 (application) : 서블릿 컨텍스트와 같은 범위 

 

- 스코프는 @Scope("prototype")과 같은 방식으로 지정 가능하다.

 

---

| 빈 스코프 - 프로토타입 스코프

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

만약, 클라이언트가 프로토타입 스코프 빈을 요청하면, 스프링 컨테이너는 해당 시점에 프로토타입 빈 생성 + DI까지 진행한다.

이후, 생성한 빈을 클라이언트에게 반환하며, 스프링 컨테이너에서는 더 이상 관리하지 않는다. 요청이 올 때마다 새로 저 과정을 진행하니까.

 

⭐ 스프링 컨테이너는 빈 생성, 의존관계 주입, 초기화까지만 관여하기 때문에 @PreDetroy 같은 메서드는 호출되지 않는다!

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

 

✔ Test

[PrototypeTest.java]

public class PrototypeTest {
    @Test
    public void prototypeBeanFind() throws Exception {
        AnnotationConfigApplicationContext ac
                = new AnnotationConfigApplicationContext(PrototypeBean.class);
        System.out.println("find bean 1");
        PrototypeBean bean1 = ac.getBean(PrototypeBean.class);
        System.out.println("find bean 2");
        PrototypeBean bean2 = ac.getBean(PrototypeBean.class);

        System.out.println("bean1 = " + bean1);
        System.out.println("bean2 = " + bean2);

        assertThat(bean1).isNotSameAs(bean2);
        ac.close();
    }

    @Scope("prototype")
    static class PrototypeBean {
        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init");
        }

        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    }
}

✔ 실행 결과

find bean 1
PrototypeBean.init
find bean 2
PrototypeBean.init
bean1 = study.springstudy.lifecycle.PrototypeTest$PrototypeBean@293bb8a5
bean2 = study.springstudy.lifecycle.PrototypeTest$PrototypeBean@2416a51
18:36:32.993 [Test worker] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@1cdc4c27, started on Sun Aug 07 18:36:32 KST 2022

여기서 알 수 있는 사실 3가지!

1) @PostConstruct는 수행되었다. 즉, 스프링 컨테이너에서 빈을 조회할 때 생성 및 초기화 메서드까지 실행된다.

2) 조회 시 각각 다른 객체가 조회된 걸 볼 수 있다. 계속 새롭게 생성함을 알 수 있다.

3) @PreDestroy는 실행되지 않았다. 초기화까지만 관여하니까 그 이후는 관리하지 않는 것이다.

 

그래서, 클라이언트가 직접 종료 메서드를 호출해야 한다. 

물론, 종료하지 않더라도 어쨌거나 객체이기 때문에 GC에 의해서 Heap 영역 정리 시 함께 제거된다.

 

🚩 프로토타입은 조회할 때 실행된다고 하는데, 그러면 가장 첫 줄의 new Annotation~(PrototypeBean.class)는 뭘 하는 걸까?

싱글톤이든, 프로토타입이든 기본적으로 스프링 컨테이너를 생성할 때 가장 첫 줄의 파라미터로 넘긴 설정 클래스 정보를 바탕으로 생성한다. 이때, 해당 정보를 바탕으로 빈 메타데이터를 생성하는데, (여기서 init 같은 정보가 들어간다고 알고 있다) 프로토타입의 경우 메타데이터까지만 생성되고 실제 빈 생성까지는 진행되지 않는다. 생성은 조회했을 때!

 

---

| 프로토타입 빈과 싱글톤 빈을 함께 사용한다면?

✔ 단순 프로토타입 사용 시 요청 과정 

- 프로토타입 빈에 count라는 빈과, count 값을 증가시키는 addCount()가 있다고 가정하자.

 

- 클라이언트가 스프링 컨테이너에 프로토타입 빈을 요청한다.

- 컨테이너는 새롭게 빈을 생성해서 반환한다. 이때, 빈의 count 필드 값은 0이다.

- 조회한 프로토타입 빈(A)의 addCount()를 호출하여 count 필드 값을 증가시킨다. 0->1

- 결과적으로 A의 count 값은 1이 된다.

 

- 이후, 또 다른 클라이언트가 컨테이너에 프로토타입 빈을 요청한다.

- 컨테이너는 마찬가지로 새롭게 빈을 생성해서 반환한다. count 필드 값은 0이다.

- 조회한 프로토타입 빈(B)의 addCount()를 호출하여 count 필드 값을 증가시킨다. 0->1

- 결과적으로 B의 count 값은 1이 된다.

 

- 여기까지만 보면 당연한 결과이다. 이번에는 싱글톤과 프로토타입을 함께 사용해보자.

[SingletonWithPrototypeTest1.java - PrototypeBean]

@Scope("prototype")
static class PrototypeBean {
    private int count = 0;
    public void addCount() {
        count++;
    }
    public int getCount() {
        return count;
    }
    @PostConstruct
    public void init() {
        System.out.println("PrototypeBean.init " + this);
    }
    @PreDestroy
    public void destroy() {
        System.out.println("PrototypeBean.destroy");
    }
}

- 프로토타입 스코프를 가진 빈이다. 내부에 count라는 필드를 가지고 있다.

 

[SingletonWithPrototypeTest1.java - ClientBean]

static class ClientBean {
    private final PrototypeBean prototypeBean;

    @Autowired
    public ClientBean(PrototypeBean prototypeBean) {
        this.prototypeBean = prototypeBean;
    }

    public int logic() {
        // DI에 의해 ClientBean 생성 시 파라미터로 PrototypeBean 객체를 주입받기 때문에 .addCount() 가능
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

- 기본적으로 싱글톤 빈이다. 

- 이때, 위에서 선언한 프로토타입 빈을 생성자 주입하였다. logic()을 통해 count 값을 늘리고 해당 값을 반환하였다.

🚩 참고로, 이런 식으로 선언하면 내부 프로토타입 스코프 객체는 직접 메모리를 해제해야 한다. (메모리 누수 문제)

 

[SingletonWithPrototypeTest1.java - singletonClientUsePrototype()]

@Test
void singletonClientUsePrototype() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);

    ClientBean clientBean1 = ac.getBean(ClientBean.class);
    int count1 = clientBean1.logic();
    assertThat(count1).isEqualTo(1);

    ClientBean clientBean2 = ac.getBean(ClientBean.class);
    int count2 = clientBean2.logic();
    assertThat(count2).isEqualTo(2);
}

- 실제 테스트 코드이다. 위에서 사용한 2개의 빈을 설정 파일로 두었으며 각각을 조회하였다.

 

✔ 요청 과정

1. ClientBean은 싱글톤이기 때문에, 스프링 컨테이너의 생성 시점에 함께 생성되고 의존관계 주입이 진행된다.

- 이때, ClientBean은 주입 시점에 프로토타입 빈을 요청하기 때문에 컨테이너는 프로토타입 빈을 생성하여 반환한다.

- 이때, 프로로타입 빈의 count 필드 값은 0이다.

2. 이후, ClientBean은 생명주기가 스프링 컨테이너와 동일하기 때문에 해당 프로토타입 빈의 참조값을 내부 필드에 보관한다.

3. 클라이언트가 ac.getBean()을 통해 컨테이너에 요청을 하면, 위와 동일한 ClientBean을 반환한다.

4. clientBean1.logic()을 호출하면, 프로토타입 빈의 addCount()를 호출하여 프로토타입 빈의 count를 0->1로 증가시킨다.

5. 이후, 클라이언트가 ac.getBean()을 통해 또 다시 컨테이너에 요청하면 동일한 clientBean을 반환한다.

- 이때, 내부에 존재하는 프로토타입 빈은 과거에 주입이 끝났다. 또 사용한다고 해서 새롭게 생성되는 것이 아니다.

6, clientBean2.logic()을 호출하면, addCount로 인해 프로토타입 빈의 count를 1->2로 증가시킨다.

 

즉, 위 과정에서 문제는 사용할 때마다 새로 생성하려고 프로토타입을 사용하는 건데, 싱글톤 빈과 함께 계속 유지되는 것이다.

- 이는, 싱글톤 빈의 생성자 주입 시점에 의존관계 주입을 받으면서 프로토타입이 새로 생기는 것이기 때문에, 주입이 종료된 이후에는 계속 유지되는 것.

 

---

| 프로토타입 빈과 싱글톤 빈을 혼용 - Provider 이용하기

- 사용할 때마다 새로운 프로토타입 빈을 생성하려면 어떻게 해야 할까?

 

1. 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 요청하기.

[SingletonWithPrototypeTest1.java - ClientBean 수정]

static class ClientBean {
    @Autowired
    private ApplicationContext ac;

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

- ac.getBean()을 이용하면 조회 시 생성 + 의존관계 주입 + 초기화 메서드까지 동작하니까 항상 새로운 프로토타입 빈이 반환된다.

- 이는, 의존관계 주입을 진행한 것이 아닌 내부에서 의존관계를 찾은 것이기 때문에 DL (Dependency Lookup)이라고 한다.

- 그러나, 이 코드는 컨테이너에 종속적이고 단위 테스트가 어렵다. 다른 방법을 사용하자!

 

[SingletonWithPrototypeTest1.java - ClientBean 수정]

static class ClientBean {
    @Autowired
    private ObjectProvider<PrototypeBean> provider;

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

- ObjectProvider를 사용하자! (혹은 ObjectFactory를 사용해도 된다! 근데 Provider는 조금 더 기능이 많다고 한다.)

- getObject()를 호출하면 스프링 컨테이너를 통해 해당 빈을 찾아서 반환해준다. (DL 기능)

- DL 기능을 제공해주는, 스프링 컨테이너에 대신 조회해주는 기능... 정도라고 생각해주면 된다.

 

🚩 프로토타입 빈을 생성하는 것은 빈 팩토리에서, 스프링 컨테이너에서 생성된 빈을 찾아 반환하는 DL 기능은 Provider가 진행.

.getObject()를 하게 되면, 빈이 생성되고, 이후 Provider가 조회하는 기능을 담당한다.

 

static class ClientBean {
    @Autowired
    private Provider<PrototypeBean> provider;

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

- 아니면, 자바 표준에서 제공하는 Provider를 사용할 수도 있다. (javax.inject.Provider)

-> build.grade에 javax.inject:javax.inject:1를 import 해줘야 함! 

- 자바 표준이기 때문에 스프링에 의존하지 않는다. 마찬가지로 DL 정도의 기능을 제공한다.

 

- Provider를 사용하면 모두 타입으로 빈을 조회한다는 특징이 있다. 이름 조회 등을 사용하려면 ApplicationContext 사용하기.

 

🚩 프로토타입 빈이 굳이 필요할까? 라는 의문

- 순수 자바코드로 계속 new 생성하면 되는 것이 아닐까? 싶을 수도 있다.

- 다만, 프로토타입 빈을 사용하면 @Autowired를 지원받을 수 있기 때문에 객체 생성 및 DI가 프레임워크를 통해 자동으로 진행할 수 있다. 물론, 자바 코드로도 가능하지만 제어를 프레임워크에 넘긴다는 건 개발자로서 매우 좋은 점이니까.

 

---

| 웹 스코프

- 웹 환경에서 동작하는 스코프. 스프링이 해당 스코프의 종료 시점까지 관리한다.

- 대표적으로 request 스코프에 대해서 알아보자.

 

✔ Request Scope

- HTTP 요청 하나가 들어오고 나갈 때까지 유지되느 스코프이다. 각 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다.

- 내부의 HTTP 요청은 sessionId 등으로 (별도의 식별자 이용) 동일한 클라이언트의 요청인지 서버 내에서 판단한다.

 

예제를 위해 build.gradle에 다음을 추가하자.

implementation 'org.springframework.boot:spring-boot-starter-web'

: 내장 톰캣 서버를 활용해서 웹 서버와 스프링을 함께 실행하게 된다.

: AnnotationConfigApplicationContext -> AnnotationConfigServletWebServerApplicationContext 기반으로 동작한다.

 

 

- 요청마다 빈 생성과 종료를 구분하기 위해서 로거 클래스를 만들어주자.

[MyLogger.java]

@Component
@Scope(value = "request") // request scope
public class MyLogger {
    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " +
                message);
    }

    @PostConstruct
    public void init() {
        // 빈 생성 시점에 UUID를 생성하여 HTTP 요청을 구분해주기
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }

    @PreDestroy
    public void close() {
        // 빈 소멸 시점에 메시지 남기기
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

- 이러면 로그에 [UUID][requestURL] message 형태로 찍히게 된다.

 

🚩 request scope의 경우, "웹 요청이 들어와야" 빈이 생성되기 때문에 단순히 의존관계 주입을 하려고 하면

스프링 컨테이너에서 찾아올 수 없기 때문에 오류가 날 수밖에 없다. 이럴 때 ObjectProvider를 사용하는 것이다!

 

 

[LogDemoInterceptor.java]

@RequiredArgsConstructor
public class LogDemoInterceptor implements HandlerInterceptor {
    private final ObjectProvider<MyLogger> provider;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        MyLogger myLogger = provider.getObject();
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        return true;
    }
}

- 간단한 인터셉터를 구현하였다. HandlerInterceptor 인터페이스에서 preHandler 메서드를 구현한다.

- 이러면 컨트롤러로 요청이 가기 전에 사전 처리가 가능하다!

 

[WebMvcConfig.java]

@Configuration
@RequiredArgsConstructor
public class WebMvcConfig implements WebMvcConfigurer {
    private final ObjectProvider<MyLogger> provider;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogDemoInterceptor(provider))
                .addPathPatterns("/log-demo");
    }
}

- WebMvcConfigurer를 구현하여 만들어준 인터셉터를 추가한다. 

- ObjectProvider의 경우 스프링이 기본적으로 주입해주기 때문에 따로 빈 등록을 처리해줄 필요는 없다.

 

[LogDemoService.java]

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final ObjectProvider<MyLogger> provider;

    public void logic(String id) {
        MyLogger myLogger = provider.getObject();
        myLogger.log("service id = " + id);
    }
}

- 간단한 서비스 계층을 구현해주었다. @Service 내에 @Component가 있기 때문에 빈 등록은 잘 된다.

- 서비스 계층의 경우 웹과 관련되는 코드가 없는 것이 좋다. (HttpServletRequest 같은)

 

[LogDemoController.java]

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    private final LogDemoService logDemoService;

    @RequestMapping("/log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        logDemoService.logic("testId");
        return "OK";
    }
}

- 컨트롤러 계층이다. /log-demo로 경로를 설정해주었으며 (인터셉터 등록 시 경로와 일치하게) 단순히 서비스를 호출하는 식으로 변경하였다.

이후, 브라우저에서 http://localhost:8080/log-demo를 실행해보면...!

다음과 같이 요청마다 결과가 매우 잘 나오는 것을 확인할 수 있다 :D

- ObjectProvider 덕분에 .getObject()를 호출하는 시점까지 Request Scope 빈의 생성을 지연시킬 수 있었다.

- .getObject()를 호출하는 시점에는 이미 HTTP 요청이 진행되고 있기 때문에 request scope 빈의 생성이 정상 처리가 된다.

    - 즉, 결과적으로 요청이 들어왔을 때 .getObject를 통해서 MyLogger가 생성된다고 보면 된다.

 

🚩 정확하게는, 요청이 들어와서 Request Scope이 필요한 시점에 ObjectProvider를 통해 Request Scope 빈을 찾아와서 (DL)

만약 있으면 해당 빈을, 없으면 새로 생성해서 리턴해준다고 보면 된다!

 

---

| 스코프에 프록시 적용하기

[MyLogger.java]

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " +
                message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }

    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }

}

- proxyMode가 추가되었다. 적용 대상이 클래스면 TARGET_CLASS를, 인터페이스는 INTERFACES를 선택한다.

- 이러면 MyLogger에 가짜 프록시 클래스를 만들고, HTTP Request와 상관없이 가짜 프록시 클랙스를 미리 빈에 주입해둘 수 있다.

 

- 코드도 수정해주자.

[LogDemoInterceptor.java]

@RequiredArgsConstructor
public class LogDemoInterceptor implements HandlerInterceptor {
    private final MyLogger myLogger;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        return true;
    }
}

 

[LogDemoService.java]

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = " + id);
    }
}

- 실행해보면 아까와 같이 잘 동작한다.

- 그렇다면, 스프링 시작 시 myLogger는 뭐가 주입된 걸까...?

- 로그를 찍어보면, CGLIB로 인한 프록시 객체가 주입된 것을 확인할 수 있다.

CGLIB를 통해 MyLogger를 상속받은 가짜 프록시 객체를 생성한다.

-> 스프링 컨테이너에 "myLogger"라는 이름으로 가짜 프록시 객체를 등록하게 된다. DI 시에도 이 가짜 프로시 객체가 들어간다!

 

🚩 실제 요청이 들어오면, 가짜 프록시 객체는 내부에서 진짜 빈을 요청하는 위임 로직을 호출하며,

클라이언트가 myLogger.logic() 호출 -> 프록시 객체가 실제 객체의 myLogger.logic() 호출 -> 실행으로 동작한다.

- 이는, 실제 request scope와 관계없이 그냥 가짜 프록시 객체이며, 싱글톤처럼 동작하게 된다. (그러나, 실제 싱글톤은 아니라는 거!)

 

- 프록시 모드를 사용하면 CGLIB를 활용한 빈 객체는 스프링 컨테이너 생성 시 딱 한 번만 호출된다. 그러나, 프록시 객체가 호출될 때마다 진짜 객체를 매번 생성할지 말지는 진짜 빈의 스코프에 따라서 달라지기 때문에, 싱글톤처럼 동작하게 되면 싱글톤이 아닌데도 그렇게 동작하는 거니까 문제가 생길 수 있다. 사용 시 주의할 것.

 

⭐ 실제 객체 조회를 필요한 시점까지 지연 처리한다는 게 핵심이며,

애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다는 게 다형성, DI 컨테이너의 강점이다.

 

---

 

이렇게 스프링 핵심원리를 완강하였다! 두 번째 듣는 건데도 굉장히 새롭고...

아직 모르는 것이 투성이라는 생각이 들었다. 더 열심히 들어야겠다... 😥💦