스프링 ioc 컨테이너는 빈 객체 의존성 관리.
객체 관리 -> 객체의 생성무터 소멸까지 생명주기(life cycle) 관리를 개발자가 아닌 컨테이너가 해준다는 뜻.
객체 관리의 주체가 프레임워크가 되니까 개발자는 로직에 집중할 수 있음.
- 빈 생명주기 콜백
콜백 : 특정 이벤트 발생 시 해당 메소드 호출되는 것처럼 조건에 따라 실행 될 수도 안될 수도 있는 개념.
스프링 빈도 같은 원리로 초기화 작업과 종료 작업 나눠서 진행.
객체 생성 -> 의존관계 주입 이라는 라이프 사이클 가짐.
즉 스프링 빈은 의존관계 주입 다 끝난 다음에야 필요한 데이터 사용할 수 있는 준비 완료됨.
스프링 빈 이벤트 라이프 사이클
- 스프링 IoC 컨테이너 생성
- 스프링 빈 생성
- 의존 관계 주입
- 초기화 콜백 메소드 호출
- 사용
- 소멸 전 콜백 메소드 호출
- 스프링 종료
Q. 사이클 압축 위해 생성자 주입 (세터, 필드 주입과 과정 다름) 통해 빈 생성과 초기화 동시에 진행하면 되자 않을까?
-> 객체 생성과 초기화 분리해야 함.
생성자는 파라미터 받고, 메모리 할당해서 객체 생성.
but 초기화는 이렇게 생성된 값들로 외부 커넥션 연결과 같은 무거운 동작 수행.
생성자 안에서 무거운 작업 같이 하지말고 분리하는 것이 유지보수 관점에서 좋다. 초기화 작업이 단순하면 생성자에서 한번에 처리 ok
빈 생명 주기 콜백 3가지
- 인터페이스 (InitializingBean, DisposableBean)
- InitializingBean : afterPropertiesSet() 메소드로 초기화 지원(의존관계 주입 끝난 후에 초기화 진행)
- DisposableBean() : detroy() 메소드로 소멸 지원 (빈 종료 전에 마무리 작업. 자원 해제 등등)
단점
- 스프링 전용 인터페이스이기 때문에 코드가 인터페이스에 의존.
- 메소드 오버라이드 하기 때문에 메소드 명 변경 불가
-
<참고>
https://dev-coco.tistory.com/170
프 : https://drcode-devblog.tistory.com/366
<질문>
-
객체의 생성과 초기화를 분리해야 하는 이유는?
-> 생성자는 파라미터 받고, 메모리 할당해서 객체를 생성함.
but 초기화는 이렇게 생성된 값들로 외부 커넥션 연결과 같은 무거운 동작 수행한다. 생성자 안에서 무거운 작업 같이 하지말고 분리하는 것이 유지보수 관점에서 좋다. -
싱글톤 빈과 프로토타입 빈의 차이점은?
-> 싱글톤 빈은 조회할 때마다 클라이언트에게 같은 빈 반환해줌. 프로토타입 빈은 조회할 때마다 새로운 인스턴스 생성해서 반환해줌. -
싱글톤 스코프와 프로토타입 스코프의 범위를 비교해보세요. (https://chung-develop.tistory.com/56)
-> 싱글톤 : 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프, 프로토타입 : 빈 생성과 의존관계 주입까지만 관여하고 더는 관리 안하는 짧은 범위의 스코프. 종료 메소드 호출 x. -
프로토타입 스코프 자동 등록 방법과 수동 등록 방법에 대해 설명해보세요. (https://chung-develop.tistory.com/56)
-> 자동등록의 경우 @Scope("prototype"), 수동등록의 경우 @Bean, @Scope 명시 후 생성자로 PrototypeBean 반환. -
언제 Singleton 빈을 사용하고, 언제 Prototype 빈을 사용하는가? (https://steady-coding.tistory.com/594, https://okky.kr/articles/990588?note=2417006)
-> 싱글톤: 상태가 없는 공유 객체, 읽기 전용으로만 상태 가진 객체
프로토타입: 사용할 때마다 상태 달라져야 하는 객체, 쓰기 가능한 상태 있는 객체, 매번 사용할 때 마다 의존관계 주입 완료된 새로운 객체 필요할 때, web과 같이 여러명이 같은 객체 사용할 때
