말로만 계속 들어오던 싱글톤.
맨날 글로 읽고 머리로는 분명 이해했다고 생각했는데 왜 이걸 쓰는건데.....? 라고 내심 속에 남아있었다.
근데 바로 1강만에 왜 써야하는지 이해해버림.
일단 자바로 만들었던 DI컨테이너는 직접 그 @Bean 에 등록된 객체를 호출할 때마다 객체가 생성되는데
클라이언트에서 호출할 때마다 그 객체를 생성하면 메모리, 성능 낭비가 심하다.
그니까 어차피 똑같은거 쓸건데 계속 복사할 필요가 없이 같은거 돌려쓰면 된다. <<< 이게 싱글톤 개념의 핵심이다.
근데 이게 좋기만 하냐? 그건 아님
싱글톤 패턴의 문제점
- 코드 자체가 많이 들어감.
- 테스트, 초기화 어렵다.
- 자식 클래스 생성 불가함.
그래서 스프링을 쓰는 것!
스프링의 싱글톤 컨테이너
- 싱글톤 패턴 구현을 위한 코드 필요없음
- 객체 인스턴스를 알아서 싱글톤으로 관리해준다.
@Configuration이란?
@Configuration은 싱글톤을 위해서 존재함.
이게 뭔소리냐?
실제 Appconfig의 클래스 타입을 보면
CGLIB이 붙은 이상한 클래스가 된다.
스프링이 바이트코드 조작 라이브러리를 사용해서 임의의 다른 클래스를 만들어서 스프링빈으로 등록하게 된다.
그래서 이름은 appConfig인데 다른 놈이 등록되어 있는 것.
내부적으로는 객체 없으면 생성하고 있으면 꺼내서 반환하도록 해서 싱글톤을 보장한다.

'커리어 > 백엔드' 카테고리의 다른 글
| [JPA] 영속성 컨텍스트 (0) | 2025.10.11 |
|---|---|
| [Spring] 빈 생명주기 콜백, 빈 스코프 (4) | 2025.10.09 |
| [Spring] 컴포넌트 스캔, 의존관계 주입 (0) | 2025.10.08 |
| [Spring] IoC, DI, 컨테이너 (0) | 2025.10.06 |
| [Spring] 객체 지향 설계와 스프링 (0) | 2025.10.04 |