Categories

Algorithm🧩
백준 📝
BookReview📕
CleanCode✨
Network 📨
Database 🗄
DevOps☁️
에러 일기📕
Etc💬
Fishy Fish 🎣
Spring🌱

싱글톤 컨테이너

웹 애플리케이션과 싱글톤

스프링이 없는 순수 DI 컨테이너의 문제점
  • 사용자가 요청을 보낼 때마다 객체가 생성된다.
  • 따라서 메모리 낭비가 너무 심하다.
  • 해결방안: 해당 객체가 1개만 생성되고, 해당 객체를 공유하여 사용하도록 설계
싱글톤 패턴
  • 클래스의 인스턴스가 1개만 생성하도록 하는 디자인 패턴
  • private 생성자로 외부에서 new 키워드를 이용할 수 없도록 한다. 
     private static final SingletonService instance = new SingletonService();

 private SingletonService() {
 }

 public static SingletonService getInstance() {
     return instance;
 }
  • 객체를 미리 생성해두는 방식의 싱글톤 패턴
  • 이미 만들어진 객체를 공유한 효율적인 방식
싱글톤 패턴의 문제점
  1. 싱글톤 패턴을 구현하는 코드 자체가 많아진다.
  2. 클라이언트가 구체 클래스에 의존하게 된다. == DIP 위반 & OCP 원칙 위반 확률 ↑
  3. 내부 속성을 변경하거나 초기화하기 어렵다.
  4. 유연한 테스트가 어렵다.

싱글톤 컨테이너

  • 싱글톤 패턴의 문제점을 해결하며 객체 인스턴스를 1개만 생성하여 관리
    = 스프링 빈과 동일
  • 스프링 컨테이너가 싱글톤 컨테이너 역할 == 싱글톤 레지스트리
  • 싱글톤 패턴의 단점(구현 코드 양, DIP, OCP, private 생성자 문제) 해결
싱글톤 컨테이너 사용 시 주의점
  • 싱글톤 방식에서는 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 stateful하게 설계하면 안됨.
  • stateless 방식의 설계
    1. 특정 클라이언트에 의존적인 필드 X
    2. 클라이언트가 값을 변경할 수 있는 필드 X
    3. 읽기만 가능해야 함
    4. 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등 사용
  • 문제 상황
    1. UserA, UserB 존재 & price를 공유 필드라 가정
    2. UserA가 10,000원 주문 후 B가 20,000원을 주문한다.
    3. 그 후 UserA의 price를 조회하면 20,000원으로 조회가 된다..

∴ 스프링은 무조건 stateless 상태로 설계해야 한다!

@Configuration과 싱글톤

  • 스프링에서는 바이트코드를 조작하는 라이브러리를 사용함.
  • CGLIB라는 라이브러리를 사용해 AppConfig 클래스를 상속받은 임의의 다른 클래스를 생성하고 다른 클래스를 스프링 빈으로 등록함
  • @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성하여 빈으로 등록하고 반환
[출처]

« 스프링 빈 설정 메타 정보
[Fishy Fish] Backend - 로그인 회원가입 페이지 »
homebdy
homebdy 개발에 이제 막 발 담근 사람. 개발에 이제 막 발 담근 사람. 개발에 이제 막 발 담근 사람. 개발에 이제 막 발 담근 사람.
comments powered by Disqus