[디자인 패턴] Singleton 총정리 근데 이제 자바를 곁들인..

Singleton

---

Singleton 패턴?

⇒ 인스턴스가 하나만 존재하는 것을 보증하는 패턴

장점

• 인스턴스가 하나만 존재하기 때문에 메모리 낭비를 방지할 수 있음
• 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기 쉬움, 데이터 일관성 보장
  • 어플리케이션의 세팅값( 배경색 ), DBCP, 로그 기록 객체
  • DBCP! 토막상식!
  • db와 서버가 연결하는 connection 작업은 비용이 큼 ⇒ 다수의 사용자 동시다발적으로 사용시 서버 다운여러 커넥션들을 미리 담아두고 클라이언트가 요청할 때마다 하나씩 꺼내서 빌려줌
  • 커넥션이 다 떨어지면 다른 클라이언트가 반환할 때까지 대기상태로 전환
  • 
  • 

다이어그램

기본 골격 : Eager Initialization (이른 초기화)

public class Singleton{
        private static Singleton singleton = new Singleton();

        private Singleton() {
                System.out.println("인스턴스를 생성했습니다.");
        }

        public static Singleton getInstance() {
                return singleton;
        }
}

• 가장 간단한 형태의 구현 방법
• 클래스 인스턴스 클래스 로딩 단계에서 생성

⇒ 해당 인스턴스를 사용하지 않더라도 인스턴스 생성 → 메모리 낭비 초래

⇒ 싱글톤 클래스가 매우 적은 리소스를 다룰 때 적절

1. Lazy Initialization : 나중에 초기화

public class Singleton{
        private static Singleton instance;

        private Singleton() {}

        public static Singleton getInstance() {
                if (instance == null) {
                        instance = new Singleton();
                }
                return singleton;
        }
}

멀티 스레딩 환경에서 객체가 하나임을 보증하지 못한다.

like 요리-음식 레스토랑

2. Thread Safe Singleton

public class Singleton {

    private static Singleton instance;

    private Singleton(){}

    public static synchronized Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }

}

getInstance()할 때마다 성능 저하 초래

3. Double Checked Locking

public class Singleton {

    private static volatile Singleton instance;

    private Singleton(){}

        public static Singleton getInstance(){
            if(instance == null){
                synchronized (Singleton.class) {
                    if(instance == null){
                        instance = new Singleton();
                    }
                }
            }
            return instance;
        }
}

• volatile : 자바의 변수를 메인메모리에 저장하겠다!
  • CPU의 캐시를 거치지 않고 메인 메모리에 직접 Read/Write 수행
  • volatile을 사용하지 않는 멀티 스레드 환경에서는 CPU 캐시에 값을 저장하게 됨.
    • 각각의 스레드가 갖는 변수의 값이 불일치
    • 
  • volatile 변수에 대한 접근은 synchronized를 사용하는 것과 동일하게 동작
    • 멀티 스레드 환경에서 하나의 쓰레드는 R/W 하고, 나머지는 Read Only할 때 적절

변수의 불일치 상황을 조금이라도 줄이기 위해 volatile 키워드와 같이 씀

JDK 1.5부터 사용가능, JVM 동작방식 이해 필요하므로 사용하지 않는 것이 권장됨

4. Bill Pugh Singleton Implementaion (빌퓨?)

• inner static helper class 사용

public class Singleton {

    private Singleton(){}

    private static class SingletonHelper{
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance(){
        return SingletonHelper.INSTANCE;
    }
}

• private inner static class를 사용하여 싱글톤 인스턴스를 생성한다.
• Singleton 클래스가 로드될 때도 로드되지 않다가, getInstance()가 호출될 때, 메모리에 로드되고, 인스턴스를 생성하게 된다.
• synchronized를 사옹하지않기 때문에 성능저하가 발생하지 않는다.

권장되는 방법, 가장 널리 쓰이는 방법

자바 리플렉션으로 파괴된다는데 이번에는 그냥 넘어가도록 하자

5. Enum Singleton

public enum Singleton {
    INSTANCE;
}

• enum이 상수인 점을 활용한 구현방식
• 로딩하는 순간 만들어진다는 단점, 상속 받아 사용 불가
• 상속 받아 사용할 경우 클래스 홀더 사용하면 되지만 여전히 확장성은 떨어짐

단점

1. SOLID 원칙 위배
   1. 단일 책임 원칙 위반 (SRP)싱글톤 클래스가 생성, 관리, 전역 상태 유지 등의 여러가지 책임을 담당하게 되면 클래스의 크기가 커지고 당연히 유지보수가 어려워 진다.
   2. 하나의 인스턴스를 보증하기 때문에, 여러가지 일을 처리할 수밖에 없는 구조다.
   3. 개방-폐쇄 원칙 위반(OCP)
   4. 싱글톤 클래스가 수정이 일어나면 싱글톤 클래스를 사용하는 클래스 쪽에서의 수정도 불가피하다.
   5. 의존 역전 원칙 위반 (DIP)싱글톤 클래스와 다른 클래스 간의 결합도가 높아질 수 밖에 없기 때문에, 객체 간의 의존성을 외부에서 주입하여 객체 간의 결합도를 낮출 수 없다.
   6. 객체는 구체적인 객체가 아닌 추상화에 의존해야 한다는 법칙 위반!

2. TDD 단위 테스트 어려움만약 싱글톤 인스턴스가 상태를 가지는 경우
3. 인스턴스 내부의 데이터 값이 변경된다는 말인데, 테스트 케이스마다 상태가 변경되기 때문에 다음에 이뤄질 테스트에 영향을 끼칠 수도 있고, 테스트 범위 설정도 애매해진다.
4. 싱글톤 인스턴스는 어디서든지 접근 가능
5. Thread Safe 문제

스프링에서의 싱글톤

IoC 컨테이너 ( 스프링 컨테이너 )

컨테이너? - 컨테이너는 보통 객체의 생명주기를 관리, 생성된 인스턴스들에게 추가적인 기능을 제공하도록 하는 것

스프링 프레임워크도 객체를 생성하고 관리하고 책임지고 의존성을 관리해주는 컨테이너가 있는데,

그것이 바로 IoC 컨테이너(=스프링 컨테이너) 이다.

객체 간의 의존성을 낮추어(느슨한 결합) 결합도는 낮추고, 높은 캡슐화를 위해 스프링 컨테이너가 사용된다.

스프링 컨테이너의 종류

스프링 컨테이너가 관리하는 객체를 빈(Bean)이라고 한다.

BeanFactory

빈 팩토리(BeanFactory)는 스프링 컨테이너의 최상위 인터페이스이다.

BeanFactory는 빈을 등록, 생성, 조회 등의 빈을 관리하는 역할을 하며, getBean() 메서드를 통해 빈을 인스턴스화 할 수 있다.

@Bean 어노테이션이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용하여 빈 등록을 한다.

• BeanFactory에 여러가지 컨테이너 기능을 추가한 어플리케이션컨텍스트(ApplicationContext) 가 있다.

스프링 컨테이너의 생성과 등록

기본적으로 스프링 컨테이너는 Configuration Metadata를 사용한다.

또한, 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용하여 스프링 빈을 등록한다.

스프링 컨테이너를 만드는 다양한 방법은 ApplicationContext 인터페이스의 구현체이다.

AppConfig.class 등의 구성 정보를 지정하여 스프링 컨테이너를 생성할 수 있다.

애플리케이션 클래스는 구성 메타데이터와 결합되어 ApplicationContext를 생성하고 초기화된다.

이후 실행 가능한 시스템 또는 애플리케이션을 갖게 된다.

만약, 스프링 빈 조회에서 상속관계가 있을 시에는 부모 타입으로 조회하면 자식 타입도 함께 조회된다. 즉, Object 타입으로 조회하게 되면 모든 스프링 빈을 조회할 수 있다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

@Configuration

스프링 컨테이너가 해당 어노테이션이 붙은 클래스를 설정 정보로 사용한다.

클래스 내부에 @Bean 어노테이션이 적힌 메서드를 모두 호출하여 얻은 객체를 스프링 컨테이너에 등록하게 된다.

스프링 컨테이너에 등록된 객체를 스프링 빈(Bean)이라 한다.

public class MemberApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class)
    }
}

@ApplicationContext(AppConfig.class)

ApplicationContext를 스프링 컨테이너라고 하며, 인터페이스로 구현되어 있다.

applicationContext.getBean(”이름”, 타입);

스프링 빈은 getBean() 메서드를 이용하여 얻을 수 있다.

xml 방식

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="..." class="...">  
        <!-- collaborators and configuration for this bean go here -->
     </bean>

     <bean id="..." class="...">
         <!-- collaborators and configuration for this bean go here -->
     </bean>

     <!-- more bean definitions go here -->
</beans>

태그를 통해 필요한 값들을 설정할 수 있다.

태그는 빈 정의를 식별하는 데 사용하는 문자열이다.

<bean class=”…” 태그는 Bean의 유형을 정의하고 클래스 이름을 사용한다.

ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");