[Quarkus] Scopes

@ApplicationScoped

어플리케이션에서 사용되는 bean instance. 주입 시점에 공유되며 기본적으로 해당 어노테이션을 사용해 bean을 생성하면 지연(lazy) 생성된다. 즉, Client proxy를 통해 메서드가 호출될 때 초기화되며 생성된다.

 

@Singleton

Client proxy가 사용되지 않는다는 점 빼고는 @ApplicationScoped 와 같다. 즉, 주입 시점에 인스턴스가 생성(eager)된다.

 

@RequestScoped

Current request(보통 Http request)와 관련이 있는 bean instance. Spring에서 사용하는 @RequestScope 와 유사하다.

 

@Dependent

pseudo-scope 을 가지는 bean instance. Instance가 공유되지 않고, 주입 시점에 새로운 bean instance를 생성해 주입한다. 해당 bean을 주입받는 bean과 연관되어 생성 및 소멸이 함께 수행된다.

 

@SessionScoped

HttpSession 객체에 의해 지원되는 scope. quarkus-undertow extension을 사용해야만 사용이 가능하다.

 

 

그냥 보기엔 @Singleton 과 @ApplicationScoped 가 매우 유사해보이는데, 어떤걸 사용해야 할까?

상황에 따라 다르다.

 

일단 @Singleton 은 client proxy를 사용하지 않기 때문에 bean이 주입될 때 바로 생성(eager)된다.

하지만 @ApplicationScoped 는 주입 시점이 아닌 주입되어 메서드가 호출될 때 instance가 생성(lazy)된다.

 

@ApplicatinoScoped 로 주입된 bean은 client proxy에 의해 오로지 메서드가 호출될 때만 bean이 생성된다. 즉, 그 이전까지는 @ApplicationScoped bean의 Field를 읽고 쓸 수 없다. 반대로 @Singleton bean은 가능하다.

 

@Singleton 은 context에서 proxy를 생성하지 않고 바로 생성해 사용하는 것이기 때문에 @ApplicationScoped 보다 조금 더 성능이 좋다. 하지만 @Singleton bean은 QuarkusMock을 통한 mocking이 불가능하다.

 

@ApplicationScoped 는 runtime 중에 소멸되고, 재생성 될 수 있다. 주입된 proxy에 의해 현재 instance로 동작을 위임하기 때문에 기존 주입시점은 잘 동작한다.

 

공식문서에서 말하길 @Singleton 을 사용해야하는 좋은 이유가 없다면, 기본값(default)으로 @ApplicationScoped 사용을 추천하고 있다.