[이펙티브 자바] 01. 객체 생성과 파괴
객체의 생성과 파괴를 다룬다. 객체를 만들어야 할 때와 만들지 말아야 할 때를 구분하는 법, 올바를 객체 생성 방법과 불필요한 생성을 피하는 방법, 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 요령을 알아본다.
아이템1. 생성자 대신 정적 팩터리 메서드를 고려하라
클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자이고, 이와 별도로 정적 팩터리 메서드(static factory method)를 제공할 수 있다.
// 기본타입인 boolean을 받아 박싱 클래스인 Boolean 객체 참조로 변환하는 정적 메소드
public static Boolean valueOf(boolean b){
return b ? Boolean.TRUE : Boolean.FALSE;
}
1.1 정적 팩터리 메서드가 생성자보다 좋은 점 다섯가지
1.1.1. 이름을 가질 수 있다.
- 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다.
- 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다.
1.1.2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.
- 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용 해 불필요한 객체 생성을 피할 수 있다.
- 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있다.(인스턴스 통제 클래스)
- 인스턴스를 통제하면 싱글턴으로 만들 수도, 인스턴스화 불가로 만들수도, 동치인 인스턴스가 단 하나뿐임을 보장할 수도 있다.
1.1.3. 반환 타입의 하위 타입 객체를 반환할 수 있다.
- 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 '엄청난 유연성'을 갖는다.
1.1.4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
- 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다.
- 심지어 다음 릴리스에서는 또 다른 클래스의 객체를 반환해도 된다.
1.1.5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
- 클라이언트는 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시할 수 있다.
1.2 정적 팩터리 메서드가 생성자보다 나쁜 점 다섯가지
1.2.1. 상속을 하려면 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
- 이 제약은 상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 장점이 될 수도 있음
2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
- 생성자처럼 API 설명에 명확히 드러나지 않아 문서를 잘 써놓고 잘 알려진 규약을 사용해 문제를 완화시켜야 한다.
아이템2. 생성자에 매개변수가 많다면 빌더를 고려하라
프로그래머들은 선택적 매개변수가 많으 때 점층적 생성자 패턴을 즐겨 사용했다.
2.1 점층적 생성자 패턴
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public NutritionFacts(int servingSize, int servings) {
this(servingSize, servings, 0);
}
public NutritionFacts(int servingSize, int servings, int calories) {
this(servingSize, servings, calories, 0);
}
public NutritionFacts(int servingSize, int servings, int calories, int fat) {
this(servingSize, servings, calories, fat, 0);
}
public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium) {
this(servingSize, servings, calories, fat, sodium, 0);
}
public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium, int carbohydrate) {
this.servingSize = servingSize;
this.servings = servings;
this.calories = calories;
this.fat = fat;
this.sodium = sodium;
this.carbohydrate = carbohydrate;
}
}
// 예제
ex) NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);점층적 생성자 패턴은 사용자가 설정하길 원치 않는 매개변수까지 포함하기 쉬운데, 이럴 경우 어쩔 수 없이 그런 매개변수에도 값을 지정해 줘야 한다. 또한 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다.
이런 문제점들을 해결하기 위해 자바빈즈 패턴이라는 대안이 나왔다.
2.2 자바빈즈 패턴
public class NutritionFacts {
// 기본 값이 없는 필수값일 경우 = -1
private int servingSize = -1;
private int servings = -1;
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public NutritionFacts() {};
public void setServingSize(int servingSize) {
this.servingSize = servingSize;
}
public void setServings(int servings) {
this.servings = servings;
}
public void setCalories(int calories) {
this.calories = calories;
}
public void setFat(int fat) {
this.fat = fat;
}
public void setSodium(int sodium) {
this.sodium = sodium;
}
public void setCarbohydrate(int carbohydrate) {
this.carbohydrate = carbohydrate;
}
}
// 예제
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setCSodium(35);
cocaCola.setCarbohydrate(27);자바빈즈 패턴은 코드가 길어지긴 했지만 인스턴스를 만들기 쉽고, 그 결과 더 읽기 쉬운 코드가 되었다. 하지만 자바빈즈 패턴에서는 객체 하나를 만들려면 메서드를 여러개 호출해야 하고 객체가 완전히 생성되기 전까지는 일관성이 무너진 상태에 놓이게 된다. 일관성이 무너지는 문제 때문에 자바빈즈 패턴에서는 클래스를 불변으로 만들 수 없으며 스레드 안정성을 얻으려면 프로그래머가 추가 작업을 해줘야한다.
2.3 빌더 패턴
위의 문제를 해결하기 위해 점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 겸비한 빌더 패턴이 생겼다. 클라이언트는 필요한 객체를 직접 만드는 대신 필수 매개변수만으로 생성자(혹은 정적 팩터리)를 호출해 빌더 객체를 얻는다. 그 후 세터 메서드로 원하는 선택 매개변수들을 설정 한 뒤 build()를 호출하면 (보통은) 불변인 객체를 얻을 수 있다.
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
private NutritionFacts(Builder builder) {
this.servingSize = builder.servingSize;
this.servings = builder.servings;
this.calories = builder.calories;
this.fat = builder.fat;
this.sodium = builder.sodium;
this.carbohydrate = builder.carbohydrate;
};
static class Builder {
private final int servingSize;
private final int servings;
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val) {
calories = val;
return this;
}
public Builder fat(int val) {
fat = val;
return this;
}
public Builder sodium(int val) {
sodium = val;
return this;
}
public Builder carbohydrate(int val) {
carbohydrate = val;
return this;
}
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
}
// 예제
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(240).sodium(35).carbohydrate(27).build();빌더 패턴은 상당히 유연하다. 빌더 하나로 여러 객체를 순회하면서 만들 수 있고, 빌더에 넘기는 매개변수에 따라 다른 객체를 만들 수도 있다. 빌더 패턴에서 객체를 만드려면 그에 앞서 빌더부터 만들어야 하기 때문에 빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있다. 또한 점층적 생성자 패턴 보다는 코드가 장황해서 매개변수가 4개 이상은 되어야 값어치를 한다.
아이템3. private 생성자나 열거 타입으로 싱글턴임을 보증하라
싱글턴이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다. 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 타입을 인터페이스로 정의한 다음 그 인터페이스를 구현해서 만든 싱글턴이 아니라면 싱글턴 인스턴스를 Mocking 할 수 없기 때문이다.
3.1 싱글턴 만들기 : public static final 멤버 변수
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() {...}
public void leaveTheBuilding() {...}
}private 생성자는 public static final 필드인 Elvis.INSTANCE를 초기화할 때 딱 한번만 호출된다. 그러나 리플렉션을 사용해 private 생성자를 호출할 수 있는데, 이러한 공격을 방어하려면 생성자를 수정하여 두번째 객체가 생성되려 할때 예외를 던지게 하면 된다. 이 방식의 큰 장점은 해당 클래스가 싱글턴임이 API에 명백히 드러난다는 점이다. 두번째 장점은 바로 간결함이다.
3.2 싱글턴 만들기 : public static 정적 팩터리 메서드
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public static Elvis getInstance() {return INSTANCE;}
public void leaveTheBuilding() { ... }
}Elvis.getInstance는 항상 같은 객체의 참조를 반환하므로 제 2의 Elvis 인스턴스는 만들어지지 않는다. (리플렉션 예외는 똑같이 적용됨) 이 방식의 장점은 API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다. 두번째 장점은 원한다면 정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있다는 점이다. 세번째 장점은 정적 팩터리의 메서드 참조를 공급자로 사용할 수 있다는 점이다. 이러한 장점들이 굳이 필요하지 않다면 public 필드 방식이 좋다.
3.3 final로 만든 싱글턴 클래스 직렬화 하기
final로 만든 싱글턴 클래스를 직렬화하려면 단순히 Serializable을 구현한다고 선언하는 것만으로는 부족하다. 모든 인스턴스 필드를 일시적이라고 선언하고 readResolve 메서드를 제공해야한다. 이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어진다.
// 싱글턴임을 보장해주는 readResolve 메서드
private Object readResolve() {
// 진짜 Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에 맡긴다.
return INSTANCE;
}
3.4 싱글턴 만들기 : 원소가 하나인 열거 타입 선언
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}public 필드 방식과 비슷하지만 더 간결하고 추가 노력없이 직렬화할 수 있고 리플렉션 공격에서도 안전하다. 대부분의 상황에서는 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이다. 단, 만들려는 싱글턴이 Enum 외의 클래스를 상속해야 한다면 이 방법은 사용할 수 없다.
아이템4. 인스턴스화를 막으려거든 private 생성자를 사용하라
이따금 단순히 정적 메서드와 정적 필드만을 담은 클래스를 만들고 싶을 때가 있다. 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한게 아니다. 하지만 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어준다. 즉, 매개변수를 받지 않는 public 생성자가 만들어지며, 사용자는 이 생성자가 자동 생성된 것인지 구분할 수 없다.
이럴 경우 private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.
public class UtilityClass {
// 기본 생성자가 만들어지는 것을 막는다(인스턴스화 방지용)
private UtilityClass() {
throw new AssertionError();
}
... // 나머지 코드는 생략
}명시적 생성자가 private이니 클래스 바깥에서는 접근할 수 없지만, 클래스 안에서 실수로라도 생성자를 호출하지 않도록 AssertionError를 던지게 한다. 이 방식은 상속을 불가능하게 하는 효과도 있다. 모든 생성자는 명시적이든 묵시적이든 상위 클래스의 생성자를 호출하게 되는데, 이를 private으로 선언했으니 하위 클래스가 상위 클래스의 생성자에 접근할 길이 막혀버린다.
아이템5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
클래스가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원을 사용해야 할 때가 있다. 이럴 경우 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식을 사용할 수 있다. 이는 의존 객체 주입의 한 형태이다.
public class SpellChecker {
private final Lexicon dictionary;
public SpellChecker(Lexicion dictionary) {
this.dictionary = Objects.requireNonNull(dictionary);
}
public boolean isValid(String word) { ... }
public List<String> suggestions(String typo) { ... }
}예에서는 dictionary라는 딱 하나의 자원만 사용하지만, 자원이 몇 개든 의존 관계과 어떻든 상관없이 잘 작동한다. 또한 불변을 보장하여 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있다.
아이템6. 불필요한 객체 생성을 피하라
똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용 하는 편이 나을 때가 많다.
String s = new String("ditto");이 문장은 실행될 때마다 String 인스턴스를 새로 만든다.
String s = "ditto"이 코드는 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용한다. 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다.
생성자 대신 정적 패터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다.
아이템7. 다 쓴 객체 참조를 해제하라
자바는 가비지 컬렉터가 다 쓴 객체를 알아서 회수해간다. 그래서 자칫 메모리 관리에 더 이상 신경 쓰지 않아도 된다고 오해할 수 있는데, 절대 사실이 아니다.
//메모리 누수가 일어나는 위치는 어디인가?
public class Stack {
private Object[] elements;
private int size=0;
private static final int DEFAULT_INITIAL_CAPACITY=16;
public Stack(){
elements=new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e){
ensureCapacity();
elements[size++]=e;
}
public Object pop(){
if(size==0)
throw new EmptyStackException();
return elements[--size];
}
private void ensureCapacity(){
if(elements.length==size)
elements= Arrays.copyOf(elements, 2*size+1);
}
}위의 코드는 특별한 문제는 없어보이나, 이 프로그램을 오래 실행하다보면 점차 가비지 컬렉션 활동과 메모리 사용량이 늘어나 결국 성능이 저하될 것이다.
이 코드에서는 스택이 커졌다가 줄어들었을 때(pop 메서드) 스택에서 꺼내진 객체들을 더이상 사용하지 않더라도 가비지 컬렉터가 회수하지 않는다. 이는 객체들이 다 쓴 참조(다시 쓰지 않을 참조)를 여전히 가지고 있기 때문이다.
가비지 컬렉션 언어는 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐 아니라 그 객체가 참조하는 모든 객체를 회수해가지 못한다. 이는 Stack 클래스가 자기 메모리를 직접 관리하기 때문에 가비지 컬렉터는 해당 메모리가 활성상태인지 비활성 상태인지 알수 없기 때문이다. 이를 해결하기 위해서는 해당 참조를 다 썼을 때 null 처리로 참조 해제 하면 된다.
다음은 pop 메서드를 제대로 구현한 모습이다.
public Object pop(){
if(size==0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // 다 쓴 참조 해제
return result;
}다 쓴 참조를 null 처리 하면 다른 이점도 따라온다. 만약 null 처리한 참조를 실수로 사용하려면 프로그램은 즉시 NullPointerException을 던지며 종료된다.
캐시 역시 메모리 누수를 일으키는 주범이다. 객체 참조를 캐시에 넣고 나서, 이 사실을 잊은체 그 객체를 다 쓴뒤로도 한참을 그냥 놔두는 일을 자주 접할 수 있다.
메모리 누수의 세 번째 주범은 바로 리스너 혹은 콜백이다. 클라이언트가 콜백을 등록만 하고 명확히 해지하지 않는다면, 뭔가 조치해주지 않는 한 콜백은 계속 쌓여갈 것이다. 이럴 때 콜백을 약한 참조로 저장하면 가비지 컬렉터가 즉시 수거해간다.
아이템8. finalizer와 cleaner 사용을 피하라
자바는 두 가지 객체 소멸자를 제공한다. 그 중 finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. 그래서 자바 9에서는 finalizer를 사용 자제 API로 지정하고 cleaner를 그 대안으로 소개했지만 cleaner는 finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다.
쓸 일이 없으므로 그만 알아보자
조금만 더 알아보자면 C++에서의 객체와 관련된 자원을 회수하는 파괴자와는 다른 개념으로, finalizer와 cleaner는 즉시 수행된다는 보장이 없기 때문에 제때 실행되어야 하는 작업은 절대 할 수 없다. 또한 수행 여부 조차 보장하지 않는다.
진짜로 그만 알아보자.
아이템9. try-finally보다는 try-with-resources를 사용하라
자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. InputStream, OutputStream등이 좋은 예다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다. 전통적으로 자원이 제대로 닫힘을보장하는 수단으로 try-finally가 쓰였다. 예외가 발생하거나 메서드에서 반환되는 경우를 포함해서 말이다.
9.1 try-finally
static String firstLineOfFile(String path) throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
}나쁘지 않지만 자원을 하나 더 사용한다면 어떨까?
static void copy(String src, String dst) throws IOException {
InputStream in = new FileInputStream(src);
try {
OutputStream out = new FileOutputStream(dst);
try {
byte[] buf = new byte[BUFFER_SIZE];
int n;
while ((n = in.read(buf)) >= 0) {
out.write(buf, 0, n);
}
} finally {
out.close();
}
} finally {
in.close();
}
}자원이 둘 이상이면 try-finally 방식은 너무 지저분할뿐더러, 두번째 예외가 첫번째 예외를 집어 삼키는 경우가 있다. 이러면 스택 추적 내역에 정보가 제대로 남지 않게 되어 디버깅이 몹시 어려워진다.
이 문제는 자바 7에서 나온 try-with-resources 덕에 모두 해결되었다.
//단수의 자원을 처리하는 해결책
static String firstLineOfFile(String path) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
return br.readLine();
}
}// 복수의 자원을 처리하는 해결책
static void copy(String src, String dst) throws IOException {
try (InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dst)) {
byte[] buf = new byte[BUFFER_SIZE];
int n;
while ((n = in.read(buf)) >= 0) {
out.write(buf, 0, n);
}
}
}try-with-resources 버전이 짧고 읽기 수월할 뿐만 아니라 문제를 진단하기에도 훨씬 좋다.
'스터디 > 이펙티브 자바' 카테고리의 다른 글
| [이펙티브 자바] 06. 람다와 스트림 (0) | 2022.09.14 |
|---|---|
| [이펙티브 자바] 05. 열거 타입과 애너테이션 (0) | 2022.09.01 |
| [이펙티브 자바] 04. 제네릭 (1) | 2022.08.24 |
| [이펙티브 자바] 03. 클래스와 인터페이스 (0) | 2022.08.20 |
| [이펙티브 자바] 02. 모든 객체의 공통 메서드 (0) | 2022.08.10 |
댓글