[Spring F/W 유틸] Dynamic Get Bean Object

1. 개요

Bean 객체를 가져오는 방법은 여러가지가 존재하며, 상황에 따라 싱글톤 패턴이 아닌 Prototype 형태로 가져와야하는 케이스가 존재하기 때문에 용도에 맞게 선택을 잘해야한다.

 

2. 방법

1항에서 이야기한 부분을 내가 개발했던 구성에 적용해본다.

 

 1) 싱글톤 객체 가져오기

@Autowired
private ApplicationContext ctx;

// Dynamic GetBean Style
public void test() {
  ctx.getBean(AccountService.class).loginCheck();
}

@Autowired 
private AccountService accountService;

// @Autowired Annotation을 통한 의존성 주입
public void test() {
  accountService.loginCheck();
}

위와 같은 형태로 @Autowired 의존성 주입을 이용해 개발하고 있다고 가정하였을 때에는 

ctx.getBean(AccountService.class) 형태로 가져오는 경우 싱글톤(단일 객체)로 생성된 Class의 Object를 가져올 수 있다.

이 경우 흔히 말해 재활용이 목적이다.

내부 변수의 경우 변동이 존재하지 않는다.

다만, 이전에서 public static 형태로 메소드 구성을 많이하지만 이 경우엔 메모리 변조 또는 조작을 통해 문제를 일으킬 수 있으므로, 스프링에선 생명주기 관리와 보안 목적으로 하여금 대부분 싱글톤 방식으로 적용한다.

 

 2) Dynamic GetBean - Prototype

 @scope("prototype") 인 경우 장점을 예를 들어본다.

  1) 특정 데이터를 처리하는 ex) 출금 하는 경우 Thread를 일회성으로 생성 삭제를 반복하는 경우 사용해볼 수 있다.

왜 Prototype으로 왜? 사용해야하는가? 

   - Scope-Prototype 인 경우에 장점은 다음과 같다.

    * 1항에서 사용된 BusinessLogic ( AccountService.class ) Setter , Getter 내지 new 생성을 통해 생성하지 않아도 의존성 주입을 하면서 새로운 Thread 객체를 사용할 수 있다.

    (Thread의 경우 한번 Inturrupted 되는 경우엔 다시 Run 또는 Start가 불가능함.)

2) 예를 들어본다.

  /user/sync.do → UserSyncThread(사용자 동기화)  →  DeptInsertCaller            -- (부서 정보  DB 삽입)

                                                                  →  UserInsertCaller             -- (인사 정보  DB 삽입)

                                                                  →  DeptPositionCaller         -- (직위 정보 DB 삽입)

                                                                  →  DeptClassPositionCaller   -- (직위 정보 DB 삽입)

 

구조를 위와 같이 잡은 이유는 단 하나다. 

ex) 사용자 1000명을 1개의 Single-Thread로 작업하는 경우 1명의 사람이 1000개의 일을 처리한다.

하지만 위의 구조는 N개의 Multi-Thread가 위와 1000개를 처리하는데에 1000 / n 병렬 처리의 이점이 존재한다.

이 경우 매번 new DeptInsertCaller()  매우 큰 자원이 발생하지만 ctx.getBean(DeptInsertCaller.class)를 통한다면 

적은 비용으로 의존성 주입까지 한번에 종결할 수 있다.

 

※ 출처 : https://gmlwjd9405.github.io/2018/11/10/spring-beans.html

인사동기화 프로세스