Spring Bean Scope와 Lifecycle
Bean의 공유 범위와 생성·초기화·후처리·소멸 단계를 이해한다.
이 문서의 목차
Overview
Scope는 Bean Instance가 어디까지 공유되는지, Lifecycle은 언제 생성·주입·초기화·후처리·소멸되는지 정의한다. Singleton은 한 Container당 보통 하나이며 “Thread-safe 보장”과 같은 말이 아니다.
핵심 용어
| 용어 | 설명 |
|---|---|
| Singleton | ApplicationContext당 공유 Instance |
| Prototype | 요청할 때마다 새 Instance, 소멸 관리는 Client 책임 |
| Request/Session | Web 요청 또는 Session 범위 |
@PostConstruct | 의존성 주입 후 초기화 Callback |
| BeanPostProcessor | 초기화 전후 Bean을 검사·변환하며 Proxy도 만들 수 있는 확장점 |
왜 필요한가
Singleton Service Field에 요청별 상태를 저장하면 여러 Thread가 값을 덮는다. 반대로 Request Scope를 Singleton에 직접 넣으면 수명이 맞지 않는다. Resource 연결은 초기화 실패와 종료 해제를 함께 설계해야 한다.
핵심 원리와 내부 동작
대표 흐름은 Instance 생성 → Dependency Injection → Aware Callback → Before Initialization → @PostConstruct → After Initialization(Proxy 가능) → 사용 → @PreDestroy다. 정확한 확장 순서는 Processor와 설정에 따라 달라질 수 있다.
flowchart LR; A[Instantiate] --> B[Inject]; B --> C[Before Init]; C --> D[PostConstruct]; D --> E[After Init / Proxy]; E --> F[Use]; F --> G[PreDestroy]
Example
@Component
class ClientHolder {
private final ApiClient client;
ClientHolder(ApiClient client) { this.client = client; }
@PostConstruct void warmup() { client.validateConfiguration(); }
@PreDestroy void close() { client.close(); }
}긴 Network 호출을 무조건 Startup에 넣으면 기동이 외부 장애에 묶인다. Fail-fast가 필요한 설정 검증과 지연 연결을 구분한다.
실무에서 발생하는 문제와 Trade-off
Prototype Bean의 @PreDestroy를 Container가 자동 호출한다고 기대하면 Resource가 샌다. 짧은 Scope를 긴 Scope에 주입할 때 Scoped Proxy/ObjectProvider가 필요할 수 있다. Singleton mutable Field, ThreadLocal 미정리, 종료 Grace Period 부족은 운영 장애가 된다.
흔한 오해
- Singleton은 JVM 전체 하나가 아니라 보통 Container당 하나다.
- Singleton Bean의 모든 Method에
synchronized가 필요한 것은 아니다. Stateless하면 공유 변경 상태가 없다. @PostConstruct시점의 객체 참조와 최종 Proxy 참조를 혼동하면 안 된다.- Prototype의 전체 소멸 Lifecycle은 Container가 추적하지 않는다.
Production Considerations
Startup/Shutdown 시간, 초기화 실패, Resource Leak을 측정한다. 종료 시 새 요청 차단→진행 작업 Drain→Resource Close 순서를 둔다. Singleton에는 요청별 Mutable State를 저장하지 않고 ThreadLocal은 반드시 remove()한다.
다른 사람에게 설명한다면
30초: “Scope는 Bean이 공유되는 범위이고 Lifecycle은 생성부터 소멸까지 단계입니다. Singleton은 Thread-safe를 보장하지 않으므로 상태 없이 써야 하며, BeanPostProcessor는 초기화 전후에 Proxy 같은 변환을 적용할 수 있습니다.”
2분: Scope 네 종류, Lifecycle 순서, Singleton 상태 Race, Prototype 소멸 책임과 Scoped Proxy를 설명한다.
Interview Questions
- Singleton Bean이 안전한 조건은?
- Prototype의 소멸 책임은 누구에게 있는가?
- BeanPostProcessor는 어디에 쓰이는가?
- Request Scope를 Singleton에 주입하려면?
Related Topics
IoC와 Container, Proxy·Advice·Pointcut으로 연결한다.
SOURCE REFERENCES
이 문서의 근거
본문은 Dev Atlas 안에서 완결되며, 검증이 필요할 때만 원문을 확인할 수 있습니다.