Bean 의 생성전략
Request 생성 전략은 HTTP 요청 한 건당 새로운 빈 인스턴스를 생성하는 스코프입니다 즉 각각의 HTTP 요청이 들어올 때마다 새로운 bean 이 생성이 되면 해당 요청이 완료되면 이 Bean 은 소멸이 됩니다 이때 Bean의 유지시간은 HTTP 요청이 끝날 때까지 값이 유지가 됩니다 이때는 IoC 와 서블릿 컨테이너의 동기화가 이루어져서 서블릿 컨테이너에서 요청이 완료가 되어서 응답이 나갔으면 IoC 컨테이너에 요청을 해서 해당 bean 을 삭제하게 됩니다
MySingletonBean
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Component
@RequestScope
public class MySingletonBean {
private String message;
public void setMessage(String message) {
this.message = message;
}
public String getMessage() {
return message;
}
}
참고로 scope는 request 가 먹지 않아서 RequestScope로 대체를 하겠습니다 그럼 이 빈은 HTTP 요청이 올 때마다 새로운 bean 을 생성하게 됩니다
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
@RestController
public class MessageController {
@Autowired
private MySingletonBean mySingletonBean;
@GetMapping("/message1")
public String message1() {
mySingletonBean.setMessage("message1 mySingletonBean 생성");
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return mySingletonBean.getMessage();
}
@GetMapping("/message2")
public String message2() {
mySingletonBean.setMessage("message2 mySingletonBean 생성");
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return mySingletonBean.getMessage();
}
}
그리고 HTTP 요청이 필요함으로 핸들러 2개를 만들고 각 핸들러에 서로 다른 값을 집어넣고 요청 순서를 /message2 -> /messag1 순서대로 요청을 하게 됩니다 그러면 일반적인 싱글톤의 결과는 후에 요청한 message1 요청의 mySingletonBean.setMessage("message1 mySingletonBean 생성"); 값을 가져오게 됩니다만 Request 스코프를 쓰게 되면 HTTP 요청 간의 독립적인 빈 이 생성됨으로 이때는 후에 요청한 messag1 값을 가지고 오는 것이 아니아 원래 요청한 값을 가져오게 됩니다
리퀘스트의 생성 전략의 장점, 단점
장점
요청마다 독립적인 상태 프로토타입처럼 새로운 HTTP 요청이 들어올 때마다 새로운 Bean 인스턴스가 생성되기 때문에 각 요청은 독립적인 상태를 가질 수 있습니다
HTTP 요청 간 동일한 데이터 유지 동일한 HTTP 요청에 한해서는 독립적인 값을 계속해서 공유할 수 있습니다
단점
메모리 누수 HTTP 요청이 끝나면 자동으로 소멸되긴 하지만 그래도 상태변화가 필요 없는 bean까지 Request로 생성할 경우 메모리 누수 및 성능 저하의 원인이 될 수 있습니다
요청 범위 밖의 상태 공유 불가능 동일한 HTTP 요청일 때만 값이 공유되지만 그 요청 바깥에 있는 상태에는 관여 또는 공유할 수 없습니다
상태 관리의 어려움 웹 애플리케이션은 수많은 요청에 의해서 움직이게 됩니다 이때 이 값이 동일한 HTTP 요청에 한해서 값이 독립적으로 공유가 되어야 하는지 아니면 전역적으로 공유가 되어야 하는지 판단을 하고 설계를 진행을 해야 합니다 그래서 복잡한 애플리케이션 일때 더욱더 세밀한 bean 생성 전략을 사용해야 합니다
오늘 시간까지 spring bean 이 생성될 전략에 대해서 공부를 해보았습니다 대표적 3가지만 알아본 것이고 이 외에도 session , websocket 다양한 방식이 있습니다 이에 대해서는 다음에 한번 다루어 보는 것으로 하겠습니다