Skip to content

Latest commit

 

History

History
48 lines (35 loc) · 2.94 KB

File metadata and controls

48 lines (35 loc) · 2.94 KB

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

싱글톤이란 인스턴스를 오직 하나만 생성할 수 잇는 클래스를 말한다 하지만 클래스를 싱글톤으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다 싱글톤 인스턴스를 mock 구현으로 대체할 수 없기 때문

  1. public static final 필드 싱글톤
public class Person {
	public static final Person INSTANCE = new Person();
	private Person() { ... }
}

private는 Person.Instance를 초기화할때 딱 한번만 호출된다 왜? public이나 protected가 아니라서 초기화될때 만들어진 인스턴스가 전체 시스템에서 하나뿐임을 보장한다 이게싱글톤이다 → 간결함, public static 필드가 final이라서 절대로 다른 객체 참조 불가 하지만 클라이언트가 사용하지 않더라도 생성되서 메모리낭비임

또 다른 방법은 정적 팩터리 메서드를 public static멤버로 제공해서 만든다

  1. 정적 팩터리 싱글톤
public class Person {
	private static final Person INSTANCE = new Person();
	private Person() { ... }
	public static Person getInstance() { return INSTANCE; }
}

첫번쨰 예제랑 같은 기능을하지만 마음이 바뀌면 싱글톤이 아니게 변경 가능 (유일한 인스턴스를 반환하던 팩터리 메서드가 호출하는 스레드별로 다른 인스턴스를 넘겨주게 할 수 있음), 원한다면 정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있음, 정적 팩터리의 메서드 참조를 공급자(supplier)로 사용할 수 있음 (Person::getInstance를 Supplier로 사용하는) 근데 이또한 사용하지 않더라도 인스턴스가 생성되서 메모리 낭비임

하지만 둘 중 하나의 방식으로 만든 싱글턴 클래스를 직렬화하려면 단순히 Serializable을 구현한다고 선언하는 것으로는 부족 → 모든 인스턴스 필드를 일시적(transient)이라고 선언하고 readResolve 메서드를 제공해야 함이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어짐 가짜 Person이 생성된다는 뜻 해결방법은 readRevolve메서드 추가

//싱글턴임을 보장해주는 readResolve 메서드
private Object readResolve() {
	// '진짜' Person 를 반환하고, 가짜 Person 는 가비지 컬렉터에 맡김
	return INSTANCE;
}
  1. 열거 타입의 싱글톤
public enum Person {
	INSTANCE;
}

이건 더 간결하고 추가 노력 없이 직렬화할 수 있다 복잡한 직렬화 상황이나 리플렉션 공격에도 제 2의 인스턴스가 생기는 일을 완벽하게 막아준다 대부분의 상황에서 원소가 하나뿐인 열거 타입이 싱글톤을 만드는 가장 좋은 방법이다 하지만 싱글톤이 enum외의 다른 클래스를 상속해야 한다면 이 방법은 불가능