2장 객체 생성과 파괴

 

이전부터 이펙티브 자바 책을 보고 싶었는데, 2월 한 달 동안 이 책을 보려고 한다. 원래는 클린 코드를 마저 보려고 했으나 자바를 깊이 있게 이해하고, 공부한 후에 클린 코드 책을 보는 것이 더 도움이 될 것 같아 이펙티브 자바를 먼저 보게 되었다. 그동안 깊게 생각하지 않고 권장되는 방법으로 사용하던 것들도 있고, 지양해야 하는 방법을 사용한 적도 있다. 앞으로 짜게 될 코드들은 모두 이유가 있는 코드들이길 바란다.

 

2장은 객체를 생성하고 파괴하면서 주의해야 할 점들에 관한 내용이다. 객체를 어떻게 생성하는지, 어떤 객체를 생성해야 하는지, 파괴를 언제 어떻게 하는지 등과 같이 알고 사용하면 너무 좋은 내용들로 구성되어 있었다. 싱글톤이면 어떤 것이 좋은지 모르고 싱글톤으로 만들어 사용하거나, 의존 객체 주입이 생성자보다 어떻게 더 좋은지 잘 알지 못하고 해왔었는데 2장을 통해 잘 알게 되었다.

 

1. 정적 팩터리 메서드

정적 팩터리 메서드는 클래스의 인스턴스를 반환한다. Boolean.valueOf()과 같은 메서드가 이에 해당한다. 생성자 대신(혹은 같이) 정적 팩터리 메서드를 사용했을 때의 장단점을 각각 정리하겠다.

 

장점

1. 이름을 가질 수 있다.
   • 클래스명 그대로 사용해야 하는 생성자와는 달리 객체를 잘 나타낼 수 있는 이름을 가질 수 있어 어떤 기능을 하는지 파악하기 쉽다.
2. 호출 시마다 인스턴스를 새로 생성하지 않아도 된다.
   • 불변 클래스의 경우 인스턴스를 미리 만들어 두거나 캐싱해둔 인스턴스를 재사용해 불필요한 객체 생성을 줄인다.
   • 인스턴스 통제가 가능하다.
     → 싱글턴, 인스턴스화 불가, 불변 값 클래스에서 동치인 인스턴스 하나임을 보장 가능
3. 반환 타입의 하위 타입 객체를 반환할 수 있다.
   
   • 구현 클래스를 공개하지 않고 객체 반환이 가능하다.
     → API 작게 유지 가능, 인터페이스 기반 프레임워크 핵심 기술
4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
   • 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다.
5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
   • 이런 유연함은 서비스 프레임워크 만드는 근간이 된다. (JDBC)
     • 서비스 인터페이스 : 구현체의 동작 정의 (Connection)
     • 제공자 등록 API : 제공자가 구현체 등록 시 사용 (DriverManager.registerDriver)
     • 서비스 접근 API : 클라이언트가 서비스의 인스턴스 얻을 때 사용 (DriverManager.getConnection)
     • 서비스 제공자 인터페이스 : 서비스 인터페이스의 인스턴스 생성하는 팩터리 객체 설명해줌 (Driver)

 

단점

1. 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
   • 상속을 하기 위해서는 public이나 protected 생성자가 필요하다
   • 상속보다 컴포지션 사용 유도, 불변 타입으로 만들기 위해 이 제약을 지켜야 함 → 장점
2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
   • 명명 방식
     • from : 매개변수 받아 해당 타입 인스턴스 반환 (형변환)
     • of : 여러 매개변수 받아 적합 인스턴스 반환 (집계)
     • valueOf : from, of의 자세한 버전
     • instance / getInstance : 매개변수 받으면 매개변수로 명시한 인스턴스 반환 (같음 보장 X)
     • create / newInstance : 매번 새로운 인스턴스 생성 반환 보장
     • getType : getInstance와 같지만 생성할 클래스 아닌 다른 클래스에 팩터리 메서드 정의 시 사용
     • newType : getType과 동일하게 newInstance와 같음
     • type : getType, newType의 간단 버전

//getType, newType, type
FileStore fs = Files.getFileStore(path);
BufferedReader br = Files.newBufferedReader(path);
List<Complaint> litany = Collections.list(legacyLitany);

 

---

2. 빌더

선택적 매개변수가 많을 때 정적 팩터리와 생성자는 대응하기 어렵다.

선택적 매개변수가 많을 때 활용할 수 있는 대안

1) 점층적 생성자 패턴

선택 매개변수 1개 ~ 전부 다 받는 생성자를 모두 만드는 방식이다.

→ 매개변수 많아지면 클라이언트 코드 작성하거나 읽기 어려움

 

2) 자바빈즈 패턴

매개변수가 없는 생성자로 객체를 만들고, setter 메서드들을 호출해 원하는 매개변수의 값을 설정하는 방식이다.

자바빈즈 패턴에서 객체 하나를 만들기 위해서는 메서드를 여러 개 호출해야 한다. 또, 객체가 완전히 생성되기 전까지 일관성이 무너진 상태가 된다.

→ 클래스를 불변으로 만들 수 없고 스레드 안전성을 얻기 위해서는 추가 작업이 필요

 

3) 빌더 패턴

점층적 생성자 패턴의 안전성과 자바 빈즈 패턴의 가독성을 겸비한 패턴이다.

보통 빌더는 생성할 클래스 안에 정적 멤버 클래스로 만들어둔다.

 

동작 방식

1. 클라이언트는 필요한 객체를 직접 만들지 않고, 필수 매개변수만으로 생성자나 정적 팩터리를 호출해 빌더 객체를 얻는다.
2. 빌더가 제공하는 일종의 setter들로 선택 매개변수를 설정한다.
3. 매개변수가 없는 build를 호출해 객체를 얻는다. (보통 불변)

이런 동작 방식을 메서드 호출이 흐르듯 연결되어 플루언트 API 혹은 메서드 연쇄라 한다. 빌더 패턴은 명명된 선택적 매개 변수를 흉내낸 것이다.

class OriginalClass{    
    public static class Builder{
        //필수 매개변수
        private final int a;

        //선택 매개변수
        private int option1 = 0; //default 값으로 초기화
        private int option2 = 0;

        public Builder(int a){
            this.a = a;
        }

        public Builder option1(int o){
            option1 = o; return this;
        }

        public Builder option2(int o){
            option2 = o; return this;
        }

        public OriginalClass build(){
            return new OriginalClass(this);
        }

    }
    
    private OriginalClass(Builder builder){
    	a = builder.a;
        option1 = builder.option1;
        option2 = builder.option2;
    }
}

장점

• 빌더 패턴은 계층적으로 설계된 클래스와 함께 사용하기 좋다.
• 유연하다.
  • 빌더 하나로 여러 객체 순회하며 객체 생성 가능
  • 매개변수에 따라 다른 객체 생성 가능
  • 객체마다 부여되는 일련번호와 같은 특정 필드는 빌더가 알아서 채우기 가능

단점

• 객체를 만들려면 빌더부터 만들어야 한다 → 생성 비용 증가 (민감한 상황에서 문제 발생 가능)
• 매개변수가 4개 이상이어야 값어치를 한다
  → 보통 API는 시간이 지날수록 매개변수가 많아지니 빌더로 시작하는 것이 나을 때가 많다.

---

3. 싱글턴 보증

싱글턴의 예시로는 함수와 같은 무상태(stateless) 객체나 설계 상 유일해야 하는 시스템 컴포넌트가 있다. 하지만 클래스를 싱글턴으로 만들면 테스트가 어려워진다.

 

다음은 싱글턴을 만드는 두가지 방식이다. 두 가지 모두 생성자는 private고 유일한 인스턴스에 접근하기 위해 public static 멤버가 있다.

 

1) public static final 멤버

INSTANCE 바로 사용

• 클래스가 초기화될 때 만들어진 인스턴스가 전체 시스템에서 하나임이 보장된다.
• 권한이 있는 클라이언트는 리플렉션 PAI인 AccessibleObject.setAccessible을 사용해 private 생성자 호출 가능 
  → 생성자에서 두 번째 객체 생성되려 할 때 예외를 던지면 됨
• 해당 클래스가 싱글턴임이 API에 드러남
• 간결함

 

2) 정적 팩터리 메서드를 public static 멤버로 제공

getInstance()로 instance 접근

• 항상 같은 객체 참조 반환해 전체 시스템에서 하나의 인스턴스임이 보장됨 (리플렉션은 위와 동일하게 막음)
• API 변경 없이 싱글턴이 아니게 변경 가능
• 정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있음
• 정적 팩터리의 메서드 참조를 공급자로 사용 가능 (Elvis::getInstance → Supplier<Elvis>

 

3) 열거 타입 선언

• 간결함, 쉬움, 복잡한 직렬화 가능, 리플렉션 공격 안먹힘
• 대부분 원소가 하나뿐인 열거 타입이 싱글턴 만드는 가장 좋은 방법이다.
• 만들려는 싱글턴이 Enum 외의 클래스 상속해야 하면 사용 불가능

 

싱글턴 클래스 직렬화

public static final이나 정적 팩터리 메서드 방식은 직렬화를 할 때 readResolve 제공이 필요하다.

• 모든 인스턴스 필드를 transient이라고 선언, readResolve 메서드를 제공해야 한다.
  이러지 않으면 역직렬화 할 때마다 새로운 인스턴스 만들어짐

---

4. private 생성자

정적 메서드와 정적 필드만을 담은 클래스를 만드는 경우, 인스턴스화를 막아야 한다.

• 기본 타입 값, 배열 관련 메서드 모아놓을 수 있음 (java.lang.Math, java.util.Arrays)
• 특정 인터페이스 구현 객체 생성해주는 정적 메서드(팩터리) 모아놓을 수 있음 (java.util.Collections)
• final 클래스와 관련된 메서드 모아놓을 때에도 사용

추상 클래스로 만드는 것은 인스턴스화를 막을 수 없다. → 하위 클래스를 만들면 쉽게 인스턴스화 할 수 있다.

private 생성자를 추가해 컴파일러가 기본 생성자를 만들지 못하도록 하면 인스턴스화 막을 수 있다.

 

---

5. 의존 객체 주입

사용하는 자원에 따라 동작이 달라지는 클래스 : 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.

• 클래스가 여러 자원 인스턴스 지원해야 함
• 클라이언트가 원하는 자원을 사용해야 함

의존 객체 주입 

인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식

• 불변 보장해 같은 자원을 사용하려는 여러 클라이언트가 의존 객체 공유 가능
• 생성자, 정적 팩터리, 빌더 모두에 똑같이 응용 가능
• 변형 : 팩터리 메서드 패턴
  생성자에 자원 팩터리를 넘겨주는 방식
• 의존성이 매우 많은 큰 프로젝트에서 코드 어지럽게 만들기도 함
  → Spring, Dagger, Guice 등의 의존 객체 주입 프레임워크 사용하면 해결 가능

 

---

6. 불필요한 객체 생성 피하기

같은 기능의 객체를 매번 생성하기보다 재사용하는 것이 나을 때가 많다.

1. 불변 객체는 언제든지 재사용할 수 있다.
2. 생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다. (가변 객체여도 사용 중에 변경되지 않을 것을 안다면 재사용 가능)
3. 비싼 객체가 반복적으로 사용된다면 캐싱해 재사용할 수 있다.
   지연 초기화(lazy initialization)로 불필요한 초기화 없앨 수 있지만 권장 X  (코드 복잡해짐, 성능 크개 개선 안됨)
4. 어댑터(뷰) : 실제 작업은 뒷단 객체에 위임, 자신은 제 2의 인터페이스 역할을 함
   → 뒷단 객체 하나 당 하나만 있으면 됨 (Map의 KeySet)
5. 오토박싱 주의 (계속 새로 만듬)
   박싱된 기본 타입보다 기본 타입 사용, 의도치 않은 오토박싱 사용하지 않도록 주의할 것

아주 무거운 객체가 아니면 객체 생성을 피하기 위해 객체 풀을 만들지 말 것!!

기존 객체를 재사용해야 한다면 새로운 객체를 만들지 말라는 말이다.

방어적 복사가 필요한 상황에서 객체를 재사용했을 때의 피해 >>> 객체 반복 생성했을 때의 피해

 

---

7. 다 쓴 객체 참조 해제

프로그램에서 객체를 더이상 사용하지 않아도 객체의 다 쓴 참조를 가지고 있으면 회수되지 않는다. 단 몇 개의 객체가 성능에 악영향을 줄 수 있다.

 

해재 방법

1. 해당 참조 다 썼을 때 null 처리 → 프로그램이 지저분해짐, 예외적인 경우에만 사용
2. 참조를 담은 변수를 유효 범위 밖으로 밀어내기

 

메모리 누수 주범

1. 자기 메모리를 직접 관리하는 클래스
2. 캐시
   • 캐시 외부에서 키를 참조하는 동안만 엔트리가 살아 있는 캐시 필요한 상황
     → WeakHashMap 사용
     • 시간이 지날수록 엔트리 가치 떨어뜨리는 방식
       → 가끔 사용하지 않는 엔트리 청소 필요
       • 백그라운드 스레드 활용 (Scheduled ThredPoolExecutor)
       • 캐시에 새 엔트리 추가할 때 부수 작업으로 수행
3. 리스너 (콜백) : 약한 참조로 지정하면 가비지 컬랙터가 즉시 수거 (WeakHashMap)

 

---

8. finalizer, cleaner 사용 지양

자바에서는 두 가지 객체 소멸자를 제공한다.

• finalizer
  • 예측 불가, 상황에 따라 위험할 수 있어 일반적으로 불필요함
  • 오동작, 낮은 성능, 이식성 문제
  • 동작 중 발생하는 예외 무시됨
  • finalizer 공격에 노출되면 보안 문제 발생 가능 → 일그러진 객체 만들어짐
    • final 아닌 클래스를 finalizer 공격으로부터 방어하려면 아무 일도 안하는 final finalize() 만들기
• cleaner
  • finalizer보단 덜 위험, 예측 불가, 느리고 일반적으로 불피리요함
• 즉시 수행된다는 보장이 없다. = 제때 실행되어야 하는 작업은 할 수 없다.
• 상태를 영구적으로 수정하는 작업에서는 절대 finalizer, cleaner에 의존하면 안됨!
• 성능 문제 심각함
• 쓰임새
  • 안전망 역할 (그럴만한 값어치 있는지 고려해야 함)
  • 네이티브 피어와 연결된 객체 - 가비지 컬렉터가 회수 불가능 (성능저하, 즉시처리 시 close 사용 고려 필요)

 

종료해야 할 자원을 담은 객체의 클래스에서 finalizer, cleaner 대신해줄 방법

AutoCloseable 구현, 클라이언트에서 인스턴스 다 쓰면 close 메서드 호출 (일반적으로 try-with-resources 사용)

이때, 각 인스턴스는 자신이 닫혔는지 추적하는 것이 좋다. close 메서드에서 필드에 기록, 객체가 닫힌 후에 불리면 예외

 

---

9. try-with-resources

InpusStream, OutputStream, java.sql.Connection 등의 라이브러리는 close 메서드를 호출해 직접 닫아줘야 한다.

 

전통적으로 사용되던 try-finally 에서 finally 안에서 예외가 발생하면 두 번째 예외가 첫 번째 예외를 사켜 스택 추적 시 첫 번째 예외가 나오지 않고, 이를 기록하게 한다면 코드가 지저분해진다.

 

try-with-resources

try-finally의 모든 문제를 해결했다.

이 구조를 사용하기 위해서는 해당 자원이 AutoCloseable 인터페이스를 구현해야 한다. (java 라이브러리에서는 거의 구현하거나 확장했음)

try( 자원 읽기 ){
	//실행
} catch( exception ){
	//예외처리
}