# 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라

🚗 싱글톤이란?

---

싱글톤은 인스턴스를 애플리케이션에서 오직 하나만 생성할 수 있는 클래스를 의미한다.

예로 스프링 기본 빈이 싱글톤이다. 스프링 빈을 싱글톤으로 사용함으로써 이점은

모든 클라이언트 별로 인스턴스를 생성할 이유가 없기 때문에 무의미한 메모리 낭비를 줄일 수 있다.

별개로 스프링에서의 빈 싱글톤은 애플리케이션 전반의 싱글톤이 아닌

스프링 ApplicationContext 내에서의 싱글톤을 의미한다.

즉, new XXXService();를 하면 새로운 객체가 Context 밖에 생성이 된다는 의미이다.

🚗 싱글톤의 주의점

---

싱글톤은 모든 클라이언트가 공유하는 자원이기 때문에 인스턴스 변수가 존재하면 안된다.

만약 인스턴스 변수를 의도치 않게 하나의 클라이언트에서 변경하게 되면 모든 클라이언트에게 전파되기

때문이다.

🚗 싱글톤의 단점

---

테스트 시 mock으로 대체하기가 어렵다. 그래서 스프링에서도 생성자 주입을 권장한다.

🚗 싱글톤 보증 방법 2가지

---

싱글톤을 구현하는 방식은 크게 두 가지이다.

• public static final 필드 방식의 싱글톤
• 정적 팩토리 방식의 싱글톤

🚗 public static final 필드 방식

---

이 방식은 public static final로 미리 객체를 생성하고, private으로 더 이상 생성하지 못하게 막아서

싱글톤임을 보증하는 방식이다.

public class Elvis {

  private Elvis() {}

  public static final Elvis INSTANCE = new Elvis();

  public void method() {
    System.out.println("Elvis.method");
  }
}

🥬 리플렉션 문제점

하지만 이 방식은 리플렉션으로 접근하면 private 생성자에 접근할 수 있다는 것이다.

아래 코드의 when절처럼 reflection을 사용하면 싱글톤이 보장되지 않는 현상이 발생하게 된다.

@Test
void 리플렉션으로_private_생성자로_인스턴스_생성()
    throws
    NoSuchMethodException,
    InvocationTargetException, InstantiationException, IllegalAccessException {
  // given
  Elvis instance = Elvis.INSTANCE;

  // when
  Constructor<Elvis> constructor = Elvis.class.getDeclaredConstructor();
  constructor.setAccessible(true);
  Elvis reflectionInstance = constructor.newInstance();

  // then
  assertThat(instance).isNotSameAs(reflectionInstance);
}

해결 방법

여러가지 방법이 있겠지만, 책에서 소개하는 내용은 생성자에서 객체가 또 생성되려 하면,

예외를 던지는 방법을 안내하고 있다. 그 방법은 책에 있지는 않지만, 아래와 같이 해볼 수 있을 것 같다.

private Elvis() {
  if (Objects.nonNull(INSTANCE)) {
    throw new RuntimeException("싱글톤이므로 생성 불가!!");
  }
}

이를 테스트 해보면 Runtime Exception으로 리플렉션 공격이 실패하는 것을 알 수 있다.

@Test
void 리플렉션_방어()
    throws
    NoSuchMethodException,
    InvocationTargetException, InstantiationException, IllegalAccessException {
  // given
  Elvis instance = Elvis.INSTANCE;

  // when
  Constructor<Elvis> constructor = Elvis.class.getDeclaredConstructor();
  constructor.setAccessible(true);

  // then
  constructor.newInstance(); // RutimeException
}

하지만 Assertj를 사용해서 검증을 하면 조금 다르게 InvocationTargetException을 발생 시킨다.

@Test
void 리플렉션_방어()
    throws
    NoSuchMethodException,
    InvocationTargetException, InstantiationException, IllegalAccessException {
  // given
  Elvis instance = Elvis.INSTANCE;

  // when
  Constructor<Elvis> constructor = Elvis.class.getDeclaredConstructor();
  constructor.setAccessible(true);

  // then
  assertThatThrownBy(constructor::newInstance)
      .isInstanceOf(InvocationTargetException.class);
}

java doc에서는 InvocationTargetException을 아래와 같이 설명하고 있다.

InvocationTargetException은 호출된 메서드 또는 생성자가 던진 예외를 래핑하는 선택된 예외입니다.

🥬 장점

• 코드가 아주 간결하다.

🚗 정적 팩토리 메서드 방식

---

이 방식은 정적 팩토리 메서드를 활용해서 메서드 내부에서 인스턴스를 반환하는 방식이다.

public class Elvis {

  private static final Elvis INSTANCE = new Elvis();
  private Elvis() {}

  public static Elvis getInstance() {
    return INSTANCE;
  }
}

🥬 API를 바꾸지 않고도 변경이 가능하다.

싱글톤이 아니도록 변경할 수 있다.

• public static final 필드 방식에서 싱글톤이 아니도록 사용하려면 클라이언트 코드가 변경 되어야 한다.
  아래의 코드가 public static final의 코드인데 클라이언트 코드는 Evlis.INSTANCE를 참조하고
  있었지만, new Elvis()를 사용하도록 코드가 변경 되어야 한다.

    public static final Elvis INSTANCE = new Elvis();

• 정적 팩토리 메서드 방식은 메서드 내부만 수정하면 되기 때문에 클라이언트 코드 변경없이
  변경이 가능하다.

    public static Elvis getInstance() {
      return new Elvis();
    }

🥬 정적 팩토리 메서드를 제네릭 싱글톤 팩토리로 만들 수 있다. ??????

🥬 Supplier로 사용할 수 있다.

아래 코드와 같이 Supplier로 사용될 수 있다는 의미인데

어떤 상황에서 Supplier와 같은 함수를 인자로 받는다고 할 경우 유용하게 사용할 수 있다는 의미이다.

Supplier<Elvis> elvisSupplier = Elvis::getInstance;

🥬 단점

상황에 맞춰 쓰는 것이기 때문에 딱히 단점이라고 볼건 없지만 아무래도

public static final 방식에 비해서는 간결하지 않다는 점이다.

정리

하지만 결국 이러한 장점들이 필요없다면 public static final 방법을 쓰는 것이 훨씬 간결하다.

🚗 직렬화 주의점

---

위에서 살펴본 두 방법은 모두 직렬화에 사용할 경우 역직렬화 할 때 같은 타입의 인스턴스가

여러개 생길 수 있다. 즉, 싱글톤이 깨진다. 그 문제를 해결하려면 인스턴스 필드에

transient(직렬화 목록에서 제외)를 추가하고 readResolve() 메서드를 아래와 같이 구현하면 된다.

정확하지는 않지만 대략적으로 Serializable 인터페이스에서 readResolve를 이용해서 역직렬화를

한다고 하는데 이렇게 오버라이딩하면, 오버라이딩된 메서드를 읽기 때문에 역직렬화에 안전하다고 한다.

실제로 Serializable은 빈 인터페이스이지만 실제로는 어떤 메서드가 존재한다고 한다. 그 중 하나가

바로 readResolve()인 것이다.

public static transient final Elvis INSTANCE = new Elvis();

@Serial
public Object readResolve() {
    return INSTANCE;
}

• @Serial: 직렬화 역직렬화의 오버라이딩 메서드가 맞는지 확인해주는 애노테이션이다.
  만약 readRsolve1()이라고 선언하면 아래와 같은 warning을 띄운다.

  Annotated member is not a part of the serialization mechanism

🚗 readResolve 메서드

---

해당 내용은 싱글톤을 기준으로 설명한다.

readResolve 메서드란 무엇인가

참고: oracle document

역직렬화 시 readResolve 메서드를 선언했다면, 인스턴스를 직접 통제할 수 있다.

인스턴스를 통제한다는 것은 싱글톤을 예로 들 수 있다.

역직렬화 시 readResolve 메서드가 선언되지 않으면 매번 새로운 객체를 생성한다.

하지만 선언되어 있다면, 메서드가 반환하는 값을 사용하게 된다.

그 원리는 ObjectInpuStream이 아래와 같은 프로세스가 있기 때문이다.

1. 스트림을 역직렬화하기 위해 반환할 준비를 한다.
2. readResolve 메서드가 선언되어 있는지 확인한다.
3. 정의된 경우 readResolve 메서드가 반환하는 객체 참조를 반환하도록 한다.
4. 그렇다고 해도 새로운 객체는 생성이되는데 이는 GC 대상이 된다.

trasient를 왜 선언해야 하는가

필요없다면 제거하면 된다. 필요 있다면 선언하고 직렬화 역직렬화를 하면 된다.

하지만 통제를 위해서 readResolve 메서드를 선언해서 통제하는 것이다.

그렇다면 없으면 도대체 직렬화를 왜 하는가?에 대한 고민이 있었다.

직렬화라는게 결국 필드를 사용하기 위해서 하는 것인데 예로 Json이 되겠다.

그렇다면 필드를 직렬화 하지 않는다면 왜 직렬화 역직렬화를 할까?

예를 하나 들어보면 AMQP가 될 수 있다. AMQP와 두 서버의 통신의 절차로 알아보자.

1. producer 서버는 직렬화해서 AMQP에 보낸다.
2. 컨수머 서버는 AMQP에서 pull한다.
3. 컨수머 서버는 이를 역직렬화 한다.

3번 절차에서 만약 컨수머는 데이터가 필요있는 것이 아니고 그냥 컨숨만 하고 싶을 경우라면

사용할 수 있다. 이때 readResolve 메서드를 선언하면 캐싱된 값을 사용하도록 할 수 있다.

readResolve 메서드는 어디에 있는가

존재하는 메서드가 아니고 리플렉션을 활용한 것이다.

ObjectInpuStream이 역직렬화 관련 클래스로 여기서 리플렉션을 사용한다.

private Object readOrdinaryObject(boolean unshared)라는 메서드가

내부적으로 invokeReadResolve()를 하는데 이는 ObjectStreamClass.java에 존재한다.

또한 아래 코드와 같이 ObjectStreamClass.java에서는 리플렉션을 사용하는 것을 확인할 수 있다.

readResolveMethod = getInheritableMethod(
                        cl, "readResolve", null, Object.class);
                    return null;

하나 더 알 수 있는것은 readObject메서드인데 이 메서드가 결국은 readResolve를 호출하게 된다.

즉, readResolve가 있는지 체크하고 있으면 사용하고 없으면 사용하지 않는 것ㅇ디ㅏ.

🚗 원소가 하나인 enum

---

책에서는 가장 바람직한 방식이라고 한다.

개인적으로 가장 이상적인 방법이라고는 생각하지 않는다.

상속도 안되고 구현도 안되기 때문이다. 그냥 일반적인 방법으로 스프링처럼 사용하는 것이 좋아보인다.

즉, 유연성이 떨어진다.

public enum Elvis {

  INSTANCE;

  public void method() {
    System.out.println("Elvis.method");
  }
}

🥬 장점

• 역직렬화에 싱글톤이 보장된다.
• 리플렉션 공격도 막아준다.

🥬 단점

• 상속이 불가능하다.